In recent months there has been a noticeable resurgence in the need for Business Architecture at both tactical and strategic levels. In my experience, there are many Enterprise Architects (EA’s) thinking about Business Architecture, but very few who are really doing Business Architecture.

The Standish Group, an IT research organisation, documents this annually and has historically found that 31.1% projects are cancelled before completion, 52.7% of projects will cost 189% of their original estimated cost and only 16% of projects are completed on-time and on-budget.

Apart from the typical Project Management and Software Delivery Governance and Optimisation improvements that can be adopted to improve this situation, a further and probably more advantageous approach would be to adopt ‘Problem Architects’.

Solution Architects (the opposite of Problem Architects) are more commonly technical specialists focused on defining a technical solution that is usually heavily dependent on ‘clear’ business requirements often formulated by users and project Business Analysts. In most cases, this tends to be an inexact science as it is often too complex, too ambiguous, and has lots of errata due to tight project specific deadlines.

–

Forrester 2010 research has found that:

“…40% of organizations now have an established business architecture program. And most of the rest are working toward creating one. For a large majority of EA teams the question has shifted from ‘When should I start my business architecture effort?’ to ‘How do I get business architecture moving?’…“

Jeff Scott, Senior Analyst at Forrester has found the following based on his research on the subject:

• “…Capability maps are not just for the business. A number of EAs are interested in building capability maps for IT. They see capability maps as a powerful tool to help improve IT’s ability to serve the business. Another perspective was, ‘If you can’t get the business to engage, start with what you know (IT) and build on it’…”

• “…Business architects from the business have a different perspective…Their business-focused viewpoints brought a lot of depth to the discussion, though it left me a little uneasy about the future of business architecture in IT. If business architecture really takes off, will it be able to survive as an IT function?…”

• “…Traditional EAs are challenged to become business architects. As I spelled out the details of how to become a more business-focused enterprise architect, one architect expressed her frustration. ‘Wait a minute! I came to IT so I could work on technical problems – not business problems.’ Her comment clearly articulates what I see as the number one challenge for EAs over this decade. Am I a technologist first and business person second or is it the other way around? I don’t think EAs will be able to keep one foot in each area for long; they will have to make a clear choice. It’s going to be a hard one…”

–

Introducing a Problem Architect, aka a Business Architect, early in projects is a good way to establish the scope and focus of the problem to be solved. It’s non-invasive to the business users because everyone can agree upon the problem at hand and it’s complementary to IT because it helps mitigate the risk of guessing what the real problem is.

I welcome your thoughts and experiences on this subject.

–