www.flickr.com
This is a Flickr badge showing public photos and videos from Chief Architect. Make your own badge here.

Search ...

Powered by Squarespace
« Desire and possibility… | Main | Required Reading: TOP 25 Most Dangerous Programming Errors »
Sunday
May172009

What good looks like…

In my opinion, one of the difficult tasks for a solution architect is to pick up a new project based on an existing solution landscape and not fall into the trap of reinforcing past mistakes. 

This blog looks at what artefacts an architect should leave behind to help the architect that follows them and who doesn’t have the background to understand every detailed decision that was made.  I would hope and expect that my fellow professional architect had left information on:

  1. The Project Background – This would explain why and when the solution was created and the key events that surrounded its development.  This gives the historical context to explain critical design decisions.  For example, the initial release for a major systems often has a large number of major architectural compromises.  Typically, these are made due to rapid decision making driven by a need to drive early benefits realisation.
  2. Terminology – It is always worth clarifying the terminology being used.  Industries, organizations and programmes all create their own languages.  These may be acronyms, code words, system names, department names, nuances on standard industry terms, or specialized industry terms that newcomers to the industry will find opaque.
  3. Key Drivers, Design Principles, Standards and Constraints - A simple, easy to read set of business and IT drivers, principles and constraints that have shaped the solution are documented and form the rationale for the business and IT solution.
  4. The Business Problem – High level requirements, business process models showing the change from the current processes to the new.  The changes in business volumes should be described e.g. forecast sales increases, faster case turn around times.
  5. An Information View – descriptions of the major data objects and their usage from a business perspective. 
  6. A Risk View - Architectural decisions are often compromises and are often taken without full information. This creates risks that the solution may not be fit for purpose or may not be fit for the future. These risks should be articulated so they can be managed. When information does become available, e.g. new requirements, the original solution may not be ideal foundation – there is a business decision to be made – do we build on a weak foundation and create an expensive legacy but gain benefits earlier or do we re-engineer the solution or is there a middle route? 
  7. An Application View – I look for at three levels. First, a high level conceptual view, this is something that I can discuss with senior business senior stakeholders and show how clearly purposed conceptual applications should meet the requirements at a logical level.  Second, I want a more detailed logical view showing logical components of the applications and the logical services provided by each.  This allows me to discuss specific functional areas with the business, it is also the key cross over point into the physical application world – it is where we translate business language into IT language.  Third, a physical view that identifies specific physical components that map to the logical components, their functionality and services, whether they are bought, reused or built, their key non-functional characteristics, descriptions of any compromises made.
  8. A Data View – Again three levels, conceptual where the major data objects identified in the Information View are mapped against the conceptual applications.  A logical view does this at a lower level and will include all data required.  The physical view will consider the physical application boundaries, the capabilities and non-functional characteristics of application components to determine the correct distribution of data across the physical applications.
  9. An Integration View – Three levels again! At the conceptual level, I want to see a set of sequenced point to point links between conceptual applications that clearly show how business activities are supported.  The integration view is where we see the solution brought to life, we see the applications interact and exchange data, we see them animated.   This is where we convince the business that we really understand the requirements and have an IT solution to deliver it.  It is also at this point that gaps in the business process and IT solution will become apparent.  We must validate the end to end business solution at the conceptual level. Then again we must deep dive at the logical level.  Physicalization of the interfaces will introduce interface technologies such as ESBs and ETL, it will rationalise the data content of interfaces, it will determine interface patterns to be used, it will reuse interfaces, it will describe and explain where deviations from the logical view have taken place.
  10. An Infrastructure View – Infrastructure generally seems to be practiced as a black art.  The application architect chats to the infrastructure about non-functional requirements and by magic a recommended infrastructure specification is produced.  The magic is in reality the experience of the infrastructure architect.  What I would rather see is the expected volumetrics for each node and link in the Integration View that were used to derive the infrastructure specification.  When I come to change the solution I can look at the actual volumetrics, the actual performance of the infrastructure, the proposed incremental changes and work with infrastructure architecture to specify any infrastructure changes.

These are ten things that I would like to see when I pick up a project.  By following the disciplines that require you to create this information as part of the design activity you will almost inevitably create a design that has what we we used to call “conceptual integrity”:

  1. Functionality is grouped logically according to the age old rules of coupling and cohesion.
  2. Data is grouped logically according to the age old rules of coupling and cohesion.
  3. Data is sourced from one and only one place.
  4. Functionality resides in one and only one place.

Violating these sometimes idealistic rules makes the architecture more complex, increases costs, increases delivery times, increases error rates, and reduces the benefits of our work.

Do I think there should be masses of documentation?  No! There should be just enough to maintain and support a solution for many years into the future.  A solution will endure much longer if it has a clear conceptual architecture based on a clear understanding of business needs and the conceptual integrity of the solution is maintained.

PrintView Printer Friendly Version

EmailEmail Article to Friend

Reader Comments (2)

Great Article Allan,
Nice to see someone detail the sections with some rationale and some things to think about for those who just don't know where to start when it comes to creating documentation. While so many feel that it should be the last thing to be done and never get to it, your comment regarding length for the purpose of those who will need to refer to it for years to come should bring home the point.
It was nice to see your narrative, as it is a nice complement to some of the versions that I've written in the past that named specific models that should be included. Your point might remind those that are intimidated by the models, that it is about much more than that.

Sharon Evans

May 25, 2009 | Unregistered CommenterSharon Evans

Thanks for the great post !!!! I have been tasked with a very large development project even though I have a small internal team for the project (2 people) for the design phase. I am planning on first creating the architecture for the solution since all of the the knowledge on the systems resides in my internal team. Then I will look at how to complement the team to deliver the solution.

I am very interested in a practical way to map the architecture since because of the size of the team I don't have the time or resources to undertake a huge design phase. The approach in this blog has just the level of detail that I am looking for. Thank you!!!

May 28, 2009 | Unregistered CommenterFelipe C

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Post:
 
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>