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.
–
Business Process Management (BPM)-InSights 
Pingback: Gartner Predicts Lack of BPM will topple many Global 2000 Companies « Business Process Management (BPM)-InSights
Pingback: BPM Quotes of the week « Adam Deane
Very good post – You highlight an issue that most companies find it difficult to handle successfully.
I think there is too much focus on the names of roles, the expertise required to fulfill a role and the organizational affiliation of the role.
The fact is that there is a need for a broad spectrum of expertise ranging from high level strategic business skills to deep technical expertise. It doesn’t really matter how it is spread over different people as long as they are brought together when needed. AND they are able to understand each other – This might require communications training and the right attitude for everybody.
If you want your EA effort to succeed I think this would be a good beginning:
First you need to assemble an EA team that WANTS to work together for the benefit of the company. Secondly you want to give the team a mandate to succeed. Thirdly you would want to ensure that the team covers all of the skills needed (maybe training is needed).
The EA team doesn’t need to be one organizational unit – It can be a virtual unit with members from different part of the organization. It is important that they have the will and the mandate to do the job.
– I will stop here – it was supposed to be a short comment 😉
Pingback: Focussed Business Strategy is making a Resurgence « Business … | Feed-O-Matic