Non-Technical Factors that Lead to Poor Architectures

It is easy for us architects to think that we control the architecture design in it's entirety. But the sad truth is that there are too many dependencies for it to be just in our control. Architecture is more than just the technical side of things. A large part of it hinders on the business problem we are trying to solve and how palatable the solution is to the end users and the IT staff. This also includes working through processes to derive to the right decisions. 

Dependencies in the non-technical areas effects nearly every area of the architecture process as they drive how the solution is created. There are a number of processes that we should consider that are direct dependents of the architecture process. To name a few: project lifecycle (PLC), software development lifecycle (SDLC) and the many governance processes. 

There are some very common challenges that we see repeatedly. These include:

• Lack of Business Case - The business case really tells us the direction in which we should be going. It eludes to scope of the project. But what is so critical about it is the rationalization of the end value of the solution. This will give architects critical information to drive the solution. With this context defined we can better gauge how to align with the organizations principles, policies and standards that will expedite the project but most importantly it will leverage assets that have been defined as aligned with the strategic imperatives of the company. 
• Poor Project Management - This combines much of the scoping, resource allocation, roles and responsibilities, project structure (program vs. project vs. a series of activities), sponsor buy-in of the project management discipline. To keep things simple and since they are all interrelated I'm consolidating into approach. The core of the issue here is that if we have no approach framework to work within then how can we ensure that the right resources are looking at the problem or that in fact we are looking at the right problems. If we fail here, how do we know what are the value add areas we need to architect or validation of the design. How can we derive to the right decisions with our any if this? The answer is that we can not.  
• Disconnected Activities - I am not necessarily think about project plans and milestones but more in line with how major activities string together. Meaning are we doing design work before requirements or specifically in design how do we come to iterative decisions on architecture cross cutting concerns such as the physical architecture and the logical architecture. What comes first? Will these be final the first time? etc. Obviously this should be clearly defined in the SDLC. However this often times is not. 
• Ad-hoc Decision Making - All of the previous bullets really lead into this, informed decision making. As architects we need to have enough information to make informed decisions. If we do not, the end solution will not be the right one. 

To validate this thinking a bit more, Gartner put together a survey in 2007 that asked these very same questions. Below are the responses from CIO's in the government sector that were ask what where the top contributors to failure in their projects. As you can see there are a lot of commonalities here. While the government sector has specific challenges, this does resonate with what we see across industries. 

 

Source: Gartner - From the CIO Trenches, Why some project fail and other succeed. 

This analysis is very interesting as it points out some obvious points but also gives us some insight into how much these factors really play in. For example, lack of governance. I like to see governance pointed out when looking at project success and failures. What it shows us that if we don't have good controls, check points, processes and enterprise reference models than it impacts our ability to deliver projects.

This means that architects are responsible for ensuring that these enterprise processes are followed and adhered to. Keep in mind this doesn't mean that we become project managers or IT application or services owners, but rather knowing when the necessary steps haven't been taken, flagging them as risks and raising visibly when needed. 

This will ensure a quality solution because we can safely say that all the right questions were addressed and all the necessary stakeholders have had the the right information to make an informed decision. 

Comments

[Bob S.]

You nailed it with this one! Architecture is more about the people and process than the technology.

[Mike Walker]

Thanks Bob!

[Adrian Grigoriu]

I would add the initial state of the Enterprise: the inertia due to culture, silo organization and the business and IT divide which would slow down or inhibit the EA adoption in the first place.
Then the lack of a reference business architecture, the various definitions of EA and its scope and incomplete EA frameworks.
The lack of authority of the E architect role. And not least, the EA lead by IT for IT.

[Franco]

I think that you should speak also from the architecture maintenance problem as good architectures turn to bad if the original architect and project team don't take care of the application and maintainers have no ideas of what they are doing.

[Mark]

Technical architecture reflects the business "architecture". (basically what Adrian is saying) It is difficult to break out of that without changing the business structure.