Complex Enterprises And Simple Architectures

  • Article
 Alik Levin    I started to read a book by Roger Sessions - Simple Architectures for Complex Enterprises. I was intrigued by the title. The number of pages made me completely curious - ~170 pages. First too pages of read made me fall in love with it. I am still reading it but I can surely tell you - it helped me to feel very confident with what I kept to myself so far deep inside.

I can say it out loud now - "Software architectures are way too complex. And it should not be THAT way".

Three Basic Problems With Existing Architectures

Roger shares his experience and give his angle on why the software architectures fail. He writes:

"First, existing approaches are too expensive to execute. Second, they take too much time to complete. Third, there is no way to validate their results."

Five Things To Make Enterprise Architecture Right

Roger provides an insight on how he thinks the enterprise architectures should be  built the right way, he writes:

"First, we define what we mean by a good enterprise architecture. Second, we use this definition to build up a mathematical model for what a good enterprise architecture looks like. Fourth, We create a process for developing a good enterprise architecture based on that model. Fifth, we validate our resulting architectures against the model  before we implement them"

Definition of Good

Rogers give pretty simple of definition of the good enterprise architecture, he writes:

"Of two architectures that generally align to business needs and IT capabilities, the better of the two is the simpler of the two. The worst of the two the one is more complex."

Simple, no? ;)

Customer Case Study #1

While the context is about enterprise architecture I am sure one can extrapolate the main principles to solution architecture. Here is the case I was involved. The customer implemented distributed solution. The solution included each and every possible MS technology and products. I was called to provide my insights about why the solution performs poorly. I was way to proud they use our technology, but they took it way too far beyond the guidelines. I told them the truth "It is way too complex". I was moved to another project shortly. No regrets. While it could be pure career blocking move - I've chosen to stick with my engineering values.

Customer Case Study #2

Another customer implemented a brand new Internet facing flagship web site. It was developed as a plain vanilla, blue print based web site (as depicted in the Architecture part). The project hit the dead line. It was implemented on budget and on features. When the problems occurred. It was easy to investigate and fix it. Period.

Consultant's Dilemma

There is eternal dilemma I cope with. A customer is excited about using one or another MS feature/technology/product. I am asked what would I recommend. I know I want to say "No" since using it would add more complexity to the project on one hand. But I need to be a good MS citizen on other hand. What should I do? I usually walk the customer through the process of implementing and maintaining it using the technology. I am trying to make sure the customer is aware of the risks. After that the customer should make a better decision.

  • What would you do?
  • What's your take on complexity/simplicity of enterprise/software architecture?

This template is made with PracticeThis.com plugin for Windows Live Writer