I don't think so. For instance I was once involved with a project and all of us architects were showcasing the architecture to some external (theoretically unbiased) industry representatives. The demo was full of technical jargon and the latest buzzwords. The entire focus of the presentation was the architecture itself. Halfway, through the presentation, one of the industry representatives asked a simple question, "Where is business side to this? What exactly are you addressing?" There were no direct or quick answers. This was a wake up call that Architecture or Technology itself is not the solution. It is an enabler or a platform that can provide what the business is looking for now and what the business will need in a certain time from now and what the business might need in the future.
Most architects (and I have been guilty of this as well) want to sound informed and sometimes as a compulsion focus too much on the technical aspect of the architecture itself. The aspects are not required in the initial stages and the individual business components can be simplified to be architecture-agnostic. It is important to address the "might need" aspects of an enterprise but they shouldn't preclude simplicity.
An architecture design should be able to address the following things:
- First and foremost, demonstrate how the architecture design addresses what is required now and what will be required in the future. Keep discussions on what might be required in the future for possibly the second iteration of architecture design. One doesn't have to stop thinking about this but essentially not over-analyze the future.
- Which services will the architecture support(organizational unit or business unit services)?
- Which services will the architecture provide( common platform or non-functional services)?
- Which components will the architecture support(organizational unit or business unit services or architectural )?
- What is the essential contract of a service(if any)? What are we asking a service to be? A service typically doesn't change, it can be wrapped or adapted but the basic service doesn't change.
- What is the essential contract of a component(if any)? What are we asking a component to be? This is sometimes the hardest part because it involves changing the existing components or services in the way they exist in the enterprise. Also it is important to differentiate between components and services ( I will try to highlight this via a separate blog post).
- Allow business requirements to be traced down to some component or module or feature. We don't want to review architecture without understanding which business problems are being solved by which features. This mapping between business requirements and the architecture design elements most probably will exist in a separate artifact.
- Resist the temptation to talk about how modules are packaged and deployed. Too many times we see an architecture design get bogged into deployment details. How a component is packaged and where it is deployed is not important at the initial stage.
Based on the above, we will try to create a broad model that includes elements most commonly used in enterprise architectures. We will start with a simple enterprise architecture model almost resembling an applications architecture and then move to the added complexity of the enterprise. Let's assume that the architecture design is "growing" as the enterprise grows. The set of architecture guidelines that we establish will guide the designer and also allow them to "re-use" the model elements that suit their solutions. We will use elements from SOA, SCA, OSGI, JBI. We will reuse ESBs, MessageBrokers, EIP patterns. The model will aim to "assemble" these sometimes diverse elements and see if an enterprise can pick and choose the ones it needs without spending significant amount of time and money on trying to have a "grand" enterprise architecture.
So the subsequent posts will continue this thought and remember, a Software architecture is not an end to itself.
The opinions and statements in this communication are my own and do not necessarily reflect the opinions or policies of CA.
