Business want flexibility and shorter time to market. A few weeks ago this is what  a CEO said in a meeting. It is mentioned in most Enterprise Architectures. But what does this goal mean for the architecture process itself or for the software development process. In this posting a like to address this relationship.

First of all I think one line of working code is worth 500 of specification. Meaning it is absolute necessary to have a shared understanding with the business about the future of the business and what parts of the architecture should be flexible or fixed. The conclusion of this dialog should be documented in a good readably document. In the end working code will give you feedback on the concept and the return on investment. In my opinion the architectural process will consist off short cycles ending with working software. The architectural concept will evolve. The business can monitor the architectural process and decide to go ahead investing or end it.

Second an architecture that enables shorter time to market will fail when the basic software development process will take longer then 11 months to produce the first result. This looks very obvious but I think is one of the neglected implications for shorter time to market.

Third the architectural and software development process is a group process. The Architect works out the idea and has to communicate this to the rest. In most projects a architect is simply outnumbered by the rest. The ratio differs between 1 to 5 or 1 to 20. I have met brilliant architects with great idea’s but this ratio stresses their communication skills.

Best architectures are made by people who have a shared understanding. This understanding grows when people work together and share ideas. Alistair Cockburn states that communication efficiency diminishes as channels get dropped.

This means a architectural document should be supported with other forms of communication. Having a good relationship withe the team is essential. Communication and trust are key for having a shared understanding

Finally the relationship between Enterprise Architecture and software development is best explained by  Kent Back: “Since most of the cost of a program will be incurred after it is first deployed, programs should be easy to change. The flexibility I imagine will be needed tomorrow, though, is likely to be not what I need when I change the code. That’s why the flexibility of simplicity and extensive tests is more effective than the flexibility offered by speculative design.” (Kent Beck, Implementation Patterns, p. 12).
 

Leave a Reply

Your email address will not be published. Required fields are marked *

CommentLuv badge

Set your Twitter account name in your settings to use the TwitterBar Section.
PageLines