Litmus test for the agillity of architecture


Today’s business environment is very dynamic. Things change all the time. Definition of business concepts such as customer or employee changes over a period of time. Business rules change more frequently than business concepts. Think about new federal regulations and rules that have to be adhered to.


 


Good architectures are flexible such that changes can be incorporated with out too much difficulty. I thought about a set of questions that you should ask about your architecture in order to assess it. Most of them stem mainly from business requirements. Here is my first cut


 


Apart from supporting well known abilities such as scalability, availability and performance, a Good architecture has following traits.


 


1)      Changes to business concepts can be incorporated easily with out a huge code re-writes. For example, you may want to add few additional attributes to employee for complying with federal regulations. A good architecture allows you to do this in a systematic way.


2)      Changes to business rules can be done with in a short period of time (a day to probably a week). Business analysts should be able to view and change business rules.


3)      Changes to human workflow can be done with out serious re-architecture.


4)      Changes to presentation layer (including changing UI flow) can be done with out serious re-architecture. Can a new channel like voice channel be added with out costly re-write?


5)      Changes in security policy can be incorporated with out serious re-architecture.


6)      Allows other systems in the enterprise to interact with it easily.


7)      Ability to trace/audit activities in the system should be easy


 


If you have got 6 or more out of 7, then you probably have a good architecture. 3-5 out of 7 means you are getting there. Any thing less than that, you better get your budget aligned for a costly re-write/re-engineering exercise.


 


These are all business scenarios that enterprise customers demand from their IT system. It’s all about agility and ability to cope up with change.


 


You don’t get all these features out of box. No amount of tutorials is going to get you there. You really have to ENGINEER for it. It means real hard work. That’s not my comment. That’s John Zachman’s. I believe it is true. His site is http://www.zifa.com


 


I am sure there should be more to this. Your comments are appreciated.

Comments (5)

  1. I’ve been contemplating these exact issues over the past few days. I’m currently moving the development of a system to SOA. I find that this kind of architecture stands up much better to the 7 traits you listed above.

    I also believe that it contributes much better to Separation of Concerns ( see Agile Management at http://www.agilemanagement.net/Articles/Weblog/Separationofconcerns.html ) between Facts, Rules, and Tasks. I find that O/R mapping attempts to automate changes to ease them, but, as an architecture, does not separate them.

    As always, I’ve enjoyed reading your thoughts on the topic. I especially like the fact that you get so many people up in arms over it. You have a knack for getting them to question some of their basic beliefs.

  2. ramkoth says:

    Udi

    Thanks for your comments. Your weblog is very interesting as well. I am looking forward to read more of your insights.

    I agree SOA gives you an opportunity to think about these issues. But, one can still build a bad SOA based solution. In fact, i will be posting some materials on those precise issues.

    Regarding your last comment: I always challenge ideas that I believe are not based on sound principles, but based on myths and legends. As part of my job, i deal with lots of customers and i see their pain in solving some of their real business requirements. They end up re-writing stuff every two years. I mean we all talk about productivity to deliver first version of the project. But, then if you don’t do serious engineering, then you end up re-writing the stuff all over again. That leaves productivity argument in dust.

    I feel the anguish enterprise customers are facing and seriously we all should do a better job in making their life little more easier.