Managing Project Architectural Challenges

The original title was “Managing Projects Implementing Crap”… but I thought that was a little too harsh. It’s reality and each organization will need to make difficult decisions as part of each implementation.…

Occasionally significant architectural principles/standards of an EA Strategic
implementation, or related project, are sacrificed, even when architectural governance
is in place. Why? In this series of blogs we will look at:

1. Some of the typical reasons and principles that are broken;
2. Try to understand why the decisions are made; and
3. How to manage and respond to the architectural issues that arise.

Some of the typical reasons and architecture principles that are violated

Having been part of many large enterprise projects since the early nineties I find that many
businesses executing on their strategy through IT related programs or projects end up making decisions that compromise key architectural principles. It begins during the project preparation phase
when an estimate is delivered. The typical large project estimating process follows a scheme similar to:

• 10 days for a very complex (i.e. Process, Report, Interface, Configuration, Enhancement…);
• 7 days for complex;
• 5 days for medium complexity; and
• 3 days for simple.

However, more often than not, the preparation and estimate seldom reflects the reality.  This ends up forcing the implementation teams, to make decisions that do not appropriately favour the architectural principles or standards.

The three significant architectural principles I typically see violated across all architectural domains (process, application, data, and technology) are:

1. Lack of reusability – The solution will meet the immediate business requirement and scope of the project, however, when the solution needs to be extended it requires significant rework, if not a complete re-implementation.
2. Solution is not operationally efficient – The requirement is implemented with many manual processes to support the end solution.
3. Lack of Sponsorship and/or Requirements – I can’t tell you how many “Build and they will come” and “Technology Drives Change” projects I have been part of and the majority of these implementations rarely
   end up being successful. The technology ends up getting implemented, but the solution does not meet the business need and the business does not use the solution.

Now this does not mean there won’t be exceptions and a process in place to manage those architecture exceptions. I’m talking about architecture design/principles that are intentionally or unintentionally violated.

In one case, having presented the architectural documentation to a small group of enterprise
and solution architects they quickly realized there was no business engagement and all principles of a single architectural domain were violated.  This caused the project to step back and re-strategize its approach.

In another example, the developers for a solution were pressured to deliver on time rather than adhering to architectural reference models and design.  A quick internal project governance meeting was held to review the options and benefits to make a decision that was best suited to the company and stakeholders versus the project.  The developers were given more time to implement
the solution the correct way.

There are examples, when suitable options and recommendations are presented to the Project Governance
Council.  However, a decision is made to not embrace the recommendations made for various reasons. Sometimes the decision does not even make it to the governance council. In the next blog we will discuss why these issues arise and how to appropriately manage and respond as an enterprise/solution architect.

What are your experiences?