An old friend called me up last week to have lunch and pick my brain on software architecture. We’ve worked together building software in the past but he’s been tempted by the dark side and is now the CEO of a startup company. He needed his engineers to build an architecture model of their running system ASAP. Fortunately, I had some materials ready for him to glance over.
After he and his engineering team read over my book, they drew up a model of their system and I reviewed it with them. First off, they fell victim to a few anti-patterns listed in the book (perhaps they skimmed over those sections):
We had a nice session looking at the diagram using a projector on the whiteboard, sketching edits on the projected image while one of the engineers made edits to the diagram in near-realtime. After a bit of question and answer between me and them, I learned that their boxes fell into three traditional IT categories: user interface, business logic, and persistence. We rejiggered the diagram so that these boxes fell into columns and then labeled the columns. Aha, it was clear this was a 3-tier system.
One of the boxes had to span tiers. They had offshored the development of that piece and its code jumbled the UI and business logic together. This became clear by the way we drew it, spanning two columns. We also discussed their future plans to rework that box and their rationale for outsourcing its development.
This led to the next part of our discussion: rationales and tradeoffs. They had described the “what” of their design, but not the “why”. Rationales and tradeoffs are simple and compact to write down but give great insight into why things were designed just so. For example, they had outsourced development in order to get to market faster and the code seems to be reliable enough, but over time it is a hindrance to modifiability.
There were two joys for me. The first was working with this fun and motivated team. Sometimes I walk in at the request of a manager and there is resentment from the team and they are surly and defensive. Not this time — we had a wonderfully productive session. They were genuinely happy about how quickly (I was there maybe 90 minutes) we cleaned up the diagram and made it express the essence of their engineering.
The second joy was in validating my book. If you’ve ever been part of a creative effort like writing a book, you know that your baby has warts but you hope that despite all its problems it is a net improvement to the world. It was great to have them skim my book, apply the ideas, and be in good shape with just a few nudges. I bet if they’d had time to read the book completely it would have been even faster. So chalk one up for practical software architecture advice.
Rhino Research is devoted to improving the state of software practice. We do this by using our industrial and academic roots to give you the freshest and most practical advice in classes and during consulting engagements.
We have taught classes for many kinds of clients, ranging from regular information technology shops, to huge internet shops, to NASA.
subscribe via RSS
