Website Design

The Value of Architecture (in real world ROI terms)

The biggest question that we, as Architects (and especially Enterprise Architects), have to answer is what is the value of Enterprise Architecture. This question is always being posed by CIOs and those at the Executive level. It’s this question that is really what holds back Enterprise Architecture from gaining it’s rightful place within the organization.

The problem is that when we answer this question, we always tend to get bogged down in the minutiae, talk in technical terms, and not relate the answer back in the language of the primary questioner. We should be answering this question in business terms and provide the CIO or the Executives the answer in terms of ROI. 

How do we do that, though? By sitting inside the organization, the only way we can show an ROI is by having a different process in place and point to the relative success or failure of that process. But that’s both impractical to the organization and actually risky from a political point of view.

The approach that I would really highly recommend is that you look to an area that has already had to deal with those questions and has done a lot of research into the entire ROI aspects – Quality Assurance / Quality Control.

Quality Control / Quality Assurance

The parallels between QA/QC and Architecture is very easy to point out. Take the worst case situation where an organization has no architecture practice in place. There’s no proper requirements gathering going on. There’s no thought out design going on. And there’s no building/testing against a central design. That situation would be a very chaotic situation.

In that worse case scenario, every time an error is built into a solution, there is going to be an effort to fixing it. And the longer that error is built on (eg. one of the original “requirements” being built against might be the missed or incorrectly included), the harder it is to correct the mistake. 

From a QA/QC point of view, the costs have actually been measured and demonstrated on a regular basis. Take the following graph:

This graph was something that I found in 2007 when I was implementing a Secure Development Lifecycle into EDS’ Application Development processes. It is a graph from a paper in “Applied Software Measurement” from Capers Jones in 1996. 1996!!! Folks, this information has been around a long time. We just haven’t bothered to apply it to Architecture.

And, let’s face it, Application Development is Application Architecture!

What this diagram shows, in Blue, the bulk of defects loaded into an Application is typically done right at the beginning of a solution, when Design and coding is occurring. You’ll notice that this is roughly in the area of 85% of issues are right at the beginning of the process. In short, where the requirements gathering and original architecture is created.

The Yellow line shows where the issues are found. So, while there are problems are created early, they aren’t really found (typically) until the next phase. And, again, based on the evidence collected, the defects are found throughout the process with around 42% being found just as a project is being put into production.

The most important line, though, is the Red line. This is the line that Executives should know about and what you, as an Architect, should be talking to them about.

Cost of Mitigating Issues

That Red line talks about what the cost is for fixing an issue. Basically, the longer you wait to find the error/issue, the more expensive it is to rectify it. If the Design stage is where an issue is introduced (eg. not all the requirements are designed to) and the issue isn’t found until the solution is put into Production, you are looking at a cost of $14000 for every $1 spent on the original design. On a really large project, that is one hell of a cost overrun.

So a few lessons from this information:

  • If you don’t do your requirements gathering correctly, your design is going to be flawed. 
  • The cost to mitigate a flawed design goes up exponentially as the project goes on.
  • The sooner that you find and deal with an issue, the lower the cost.
  • Most issues are caused by a poor design.

Okay, good to know. And now we can talk about actual costs associated with poor design. And, before someone says “But that’s just one study”, there’s more studies just like that. Look into QA/QC and you’ll find all sorts of this type of information. Here’s another table that I found:

This table came from EDS’ own internal QA/QC department based on what they were seeing in terms of costs to fix a poorly design application. Now, remember, this was back in 2006/7 and EDS is no longer in existence but, still, for those of you working in larger organization I would suggest you have a conversation with your Application Development QA/QC teams to find their specific ratios. I’d be surprised if there wasn’t something very similar.

The Argument for the Architecture Practice

Okay, now you have some numbers that you can provide to Executives and can give them an idea of what will result in a project from poor design or project delivery with a poor Architecture. So how do you make the argument for the Architecture practice?

Well, let’s go back to that original diagram. Where are the most issues introduced? Back during the Design and Code stage. So what do you do? You put in governance to ensure that the design is done properly. 

Do you see what’s going on now? You actually are able to change the conversation from “what’s the value of EA?” to “How do we improve the ROI of the IT delivery?”. That’s a HUGE conversation swing. You don’t have to justify your Architecture practice, you now have to show actual savings.

Here’s the thing though. You don’t want to get too heavy with the governance. Remember, there’s a ROI associated with this conversation. So if you add timeframes and effort in the form of Architecture governance, the ROI will actually start to play off the cost of the governance processes so the ROI is no longer effective. 

Do you want the Requirements reviewed and approved? Yes. Do you want the scope of the project to stay constant? Hell yes because taking items out of scope will dramatically increase the costs AFTER PRODUCTION IMPLEMENTATION (see the graph with the $14000 cost Post Release). So just because a PM says it will save money to make the scope of the project smaller, that’s correct in the very short term. But in the long term, a strategic approach will save sooo much more money.

Focus on where the issues are going to be found with your governance to maximize the ROI. Requirements Gathering and Initial Architectures are where the most issues are going to arise so focus your governance on those areas. Governance later on isn’t going to provide that much ROI simply because there aren’t going to be as many issues that arise at that time. Be more focused at the front end than on the back end and your project costs should go down.

Same goes for strategy. When a PM wants to de-scope items, show your Executives the costs of coming back and fixing or dealing with an issue post implementation and how much more expensive it is at that time rather than during the project itself. Don’t let the PM win simply because they can’t deliver on time and on (in all likelihood) a poor initial budget estimate. Show the costs after the fact and you are talking your Stakeholder’s language.

And that’s the language of ROI.