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

Search ...

Powered by Squarespace

Enterprise Architecture Blog

Discussion focusing on how to manage an enterprise architecture function successfully.


How to make it right…

There are times when your gut instinct tells you that a solution is wrong.  The architecture or design is not clean, functionality seems to be in the wrong place, interfaces feel like they should be different, data is duplicated or tramped all over the landscape, the solution seems too complex, it appears inflexible, it seems to be storing up problems for the future. 

However, convincing people that there is a problem and that an alternative approach is better can be difficult.    The project or program has a momentum that is carrying it towards the creation of an expensive and avoidable legacy.

Before we consider what you should do let us quickly clarify what not to do!  DON’T…

  • Get angry– it may be frustrating but you must be seen to be calmly working in the interests of the business.
  • Get negative – you must be seen to be passionately behind the business goals.
  • Don’t waste your ammunition by putting forward weak unsubstantiated arguments. 
  • Appeal to abstract architectural principles – while they may make perfect sense to architects, generally no-one really cares!  (This may appear to be heresy – but I will return to this)
  • Lose credibility.

Now let us look at how to move forward…

The first point is that within a project you don’t normally have much time.  You must be focused, effective and efficient in substantiating your gut instinct, preparing and delivering your argument to the right people, and getting a project to reconsider its course.

Step 1: Determine your goal

Find out when key decisions are taken, when the project becomes committed to a course of action (e.g. contracts get signed, resources are assigned, work starts, announcement are made, egos are on the line).  This determines what you can achieve:

  • You don’t have time to understand the issues fully – your aim here is to make sure that decision makers have “wiggle room” and can change their mind at a later date rather than force through a bad solution.
  • You have time to frame the problem and present it to the right people – your goal is to persuade them to create time and make resources available to find the right way forward.
  • You have time and access to the resources you need to prepare a solution and get backing for it.  This is rare ideal where you can be the leader.

Step 2: Understand the business drivers

Its all about benefits… what are they? Are they increased revenue, reduced costs, keeping up with the market, reputation protection, risk reduction, regulatory or statutory changes?  When are they due to be delivered?  What has been promised to investors?  Are there any regulatory or statutory deadlines?  Whose ego is on the line?

The business case for a project is the obvious place to look.  However, business cases should paint a prudent picture and are written to overcome a hurdle in the investment process.  Expectation could be significantly different, there may be other hidden or implicit or intangible benefits that are much more compelling to the key stakeholders.  Understanding the business sector and the stakeholders is key to getting a full and accurate understanding of business drivers.

Timing of benefits delivery is often a major driver for compromise.  If your proposals are perceived to reduce the level of benefits or put the timing at risk, then you will probably lose credibility.

Step 3: Understand which business drivers are threatened

I was lead architect for a project where we were introducing a new channel for a client.  I felt very uncomfortable in taking the current architecture forward but I couldn’t pin point why.

The simplest solution to introduce the new channel was to extend the current solution.  However, it felt like functionality was incorrectly distributed between applications and we would be making things worse.

What I needed to do was to identify the impact on the business drivers.  I knew that the client was growing this part of the business but there was no clarity over how it would do so.

I knew how the application should have been built, I new how I wanted to take it forward.  I could only make a vague case about enabling future business flexibility which would add cost and risk to the current project.

I managed to find a stakeholder, after much enquiry, who was prepared to very forcefully articulate the future direction of the business.  He wasn’t particularly senior, he was not a key decision maker, but he was respected and influential.   He was very interested in the threats to this future and was prepared to sponsor a rethink.

I struck lucky which enabled me to challenge (via a proxy) the accepted thinking and get rational compromise to be made and a longer term roadmap to be developed.

If you can’t make the case, then you have to accept the solution as is and move forward.

A word on architecture principles…

Each principle should have a rationale that is clearly based on business needs.  If a solution violates a principle then look to the rationale to identify the business imperative that the principle is designed to support.  While the principle may not interest many stakeholders, the underlying rationale should do.

Step 4: Understand the stakeholders

Architects often raise concerns where the longer term flexibility of solution has not been thought through or where a solution appears to cause problems in another area of the organisation. 

As a solution architect, your responsibility is to ensure that the right solution for the organization is defined.  “Right” is defined by the “business” – however, the “business” is an ambiguous concept.  The justification for all architectural decisions must be “to meet business requirements”.

The key to resolving the architectural concerns is to involve all affected stakeholders in the project and ensure they express their requirements for the longer and shorter term.  If you have all the key stakeholders who will be affected by a project in both the short and long term then you will be able get requirements, constraints and directives that provide the business rationale for architectural arguments.

Obviously, to get requirements from stakeholders you need to know who they are.  If you already have a network of contacts then this will be easy.  If you don’t then you will need to find some allies to help you identify key stakeholders.

With business requirements to back your arguments, you can give the program or project manager the “wiggle room” they need to start to change the project remit to take into account architectural concerns.

If you can’t get the business backing, then you have to accept the solution as is and move forward.

Step 5: Address objections

Sometimes there is push back that states “this is scope creep” or “this project is for XYZ business unit” or “we haven’t got time”.

Scope is best dealt with by specifically de-scoping requirements with knowledge of all requirements and an understanding of the implications of de-scoping.  The de-scoped requirements allow others to take appropriate action with the knowledge of the project.  It enables a roadmap to be developed to address de-scoped items.  Refusing to collect requirements is not a reasonable approach.

Limiting stakeholder involvement based on who the sponsor is or which business unit has get the major benefits is also not reasonable or wise.  Proper stakeholder analysis is essential and all affected stakeholders should be invited to contribute requirements.

Time is a legitimate concern but the reality is that only a small amount of time is required.   Architectural decision making normally requires high level direction across a broad area and perhaps more detailed requirements for small but critical areas.  Key people can be seen on their own at time to suit them.  You don;t always need workshops, it is amazing what can be achieved in 15 minutes if you try!

Step 6: Drill down on the business impacts

The initial "gut instinct” about the solution that caused your concern should now be expressed as requirements that are at risk.  They may be:

  • non-functional requirements about performance, scalability, security, reliability, etc
  • business requirements relating to future proofing, broader business areas affected by the project, downstream project dependencies, etc

You will need to understand the benefits of achieving and the impact of not achieving these requirements.

Step 7: Frame your initial solution options

Your solution options should include:

  • The original baseline option that you were initially uncomfortable with.  In addition, you will need to develop an outline roadmap that delivers the additional needs.
  • The ideal option, this will be perfect design that you would produce if you were starting again.  You may have to rule this out immediately if the distance from reality to perfection is too great.  But it does give you a benchmark.
  • A small number of options (realistic maximum is around 3) with outline roadmaps that provide different routes to meeting the business needs or different levels of compromise to those benefits.

There should be significant differences between the options.  They may have different:

  • benefit levels
  • timing of benefits
  • business processes
  • levels of automation
  • business or IT risk levels
  • business or IT resource requirements
  • needs for business involvement
  • costs and cost profiles
  • lifetimes
  • components
  • configurations
  • data distributions
  • non-functional characteristics
  • interfaces
  • approaches to re-engineering
  • refactoring plans
  • etc.

For each option a high level delivery plan with an initial assessment of business benefits and impacts with timing should be developed.

You now have the evidence to persuade key stakeholders that the program or project needs to take a step back and identify the best way forward.

Step 8: Carry out a feasibility study

All the previous steps typically have to be carried out rapidly and sometimes superficially because you may not have fully contained the momentum of the project or program.

If you have managed stakeholders and framed the options adequately then you should be in a position to investigate the identified options, identify the trade-offs, make a recommendation and develop the new solution architecture and roadmap.

Finally, Expect the unexpected

This will not go as planned.  Despite logic, decisions you don’t understand will be made.  You will never get the full story.  You will never fully understand the stakeholders and their motivations.

If you don’t get what you want then accept defeat gracefully.

Be careful.


Desire and possibility…

Solution architecture is a compromise between desire and possibility.  The project stakeholders want everything instantly, even those things they haven’t thought of yet, at zero cost with zero defects.  We are not there so we have to trade-offs  We make compromises over:

  • Involvement – we do not consult all stakeholders, we accept that some users may not get the features they want, we accept that we may create mis-alignment between business processes, we accept that we may make another stakeholder’s job more difficult, we accept that we may not capture all requirements
  • Requirements – some requirements are de-scoped, some tasks are not automated, we accept a less than 100% solution, we work on the Pareto principle
  • Future proofing – we accept that there is not always time or resources to identify the best long term solution, we accept that we may create problems for other projects later, we accept that our solution may have a shorter life than necessary
  • Timescales – I wrote about how important the time dimension in the Zachman framework is when scheduling delivery and the need to take it into account in the solution architecture.  Business cycles and business events shape the delivery slots available to a project, we must aim to construct projects that start streams of benefits realisation in these slots.  This time based project shaping compromises requirements and solution design.
  • Costs – we choose not buy a software module, we choose cheaper suppliers, we cajole project teams to be quicker, we force code through testing, we skimp on user training, we are less than thorough on defining operational procedures, we delay building redundancy into the infrastructure, we “deliver” to budget.
  • Quality is defined as “fit for purpose”.  Often, we fail to clearly define the purpose of a solution.  Who are the stakeholders?  What are the objectives and constraints?  Unless we know these then measures such as number of outstanding bugs, defect density, number of requirements met find their own context and skew decision making.

Before I take an existing architecture forward I want to understand the compromises made and why.  I want to understand:

  • The architecture and design short cuts taken and whether they pose risk to the next and future releases of the solution.  Should my solution lay a roadmap for unpicking these compromises?
  • The pressures and constraints that have shaped decisions that will either form ongoing influences on the solution or will create risk or will need to be addressed in this release.
  • If there are political traps that I may fall into when I uncover a major constraint?

In my last blog, I described what documentation that I would like to find when I join a new project to develop the solution architecture.  The key c0ntextual information to understand the compromises made are:

  • The Project Background – To provide the historical context to explain critical design decisions. 
  • Key Drivers, Design Principles, Standards and Constraints – The business and IT drivers, principles and constraints that shaped the solution.
  • A Risk View – Documentation of architectural decisions that were made without full information and create a risk that the solution may not be fit for purpose or may not be fit for the future. 

If this information exists, then it should be reviewed and an initial set of project risks drawn up from it.  In the absence of this information, it is diligent to find out what compromises were made in each of the areas above and develop the risk assessment based on this information.


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.


Required Reading: TOP 25 Most Dangerous Programming Errors

Thank you to Karen Lopez of InfoAdvisors for this link CWE/SANS TOP 25 Most Dangerous Programming Errors


Seven Rules of Business Alignment

I have written an article for the Cutter IT Journal.  In it I describe an operating model for business alignment. You can also download a complimentary copy of the Cutter IT Journal from this link entitled "Negotiating the Path to Business Architecture/IT Architecture Alignment".

Page 1 ... 2 3 4 5 6 ... 13 Next 5 Entries »