Will The Real Business Architect please stand up?

During a presentation on Business Architecture at Forrester's Enterprise Architecture Forum in London last week, someone asked the question - 'just who are these Business Architects anyway?' A couple of people in the audience dared to raise their hands and claimed to be this new breed of professional, but where did they come from and are they really doing Business Architecture?

I believe that there are at least 3 breeds who now claim to be Business Architects.

1. The Enterprise Business Architect
2. The Domain Business Architect
3. The Project Business Architect a.k.a the Business Analyst

So, let's make it clear - Business Architecture is not something you do at the Project level. Forrester agrees that Business Architects are not Business Analysts. In 'The Up-And-Coming Business Architect' by Jeff Scott and Katie Smillie, they say:

"Forrester believes that these roles are quite distinct, with business architects designing and analyzing the "what" of the business at a higher, more strategic, and often enterprisewide level, while business analysts typically contribute to the "how" of business operations, processes, and projects."

Also, if we look at how the Business Architecture Community defines Business Architecture, as:

"A disciplined approach to creating and maintaining a set of business-owned information assets that serve as a blueprint for the planning and execution of strategy.

• First and foremost, Business Architecture is developed by the business for the business.
• Business Architecture provides a common, enterprise-level business language and framework for documenting how the business is structured."

It is clear from this definition that Business Architecture is about the planning and execution of strategy, which is usually done at the Enterprise and Domain or Line-Of-Business levels, and not at the Project level.

So, lets now look at this in more detail and try to understand what artefacts you may find in a Business Architecture at the different levels. In the following framework I've listed artefacts from an Architectural perspective, i.e. Contextual provides the 'Why?', Conceptual states the 'What?', Logical says 'How?', and Physical says 'With What?'

At the Enterprise level, given the Business Goals, the Business Architect is focused on strategic business modelling and planning for the whole business. At the Domain level, given the Enterprise Business Strategy, the Business Architect develops strategy, business models and roadmaps for the specific domain or line-of-business. Where the Domain is IT, the focus is therefore on the IT Strategy and execution through the Application portfolio. This brings us to the Project level, where the Business Architecture defined at the Enterprise and Domain levels, together with the Technical Architecture, provides the Enterprise Architecture context for the project. In reality, the context for Projects can be far more complex and can include many other sources, and the artefacts shown are not a comprehensive set for projects. But, this is not a blog about project analysis and design, our focus is Business Architecture, so in future posts we'll be looking at the artefacts shown at the Enterprise and Domain levels in much more detail.

Where Business and IT collide

Lets start by asking where should Business Architecture sit within an organisation? Well, it depends. (See Chief Architect blog - "Should IT include a business architecture function?")

If we look at Business Architecture as a function that designs the business operating model and is focused on business transformation, then it will most likely operate as some sort of Strategy and Planning function within the business.

From an IT perspective, where Business Architecture sits depends on the maturity of the Enterprise Architecture function. With a mature EA function that includes Business Architecture, for IT to deliver effectively it will typically turn to the EA function to clarify the business operating model and formalise it as part of the Enterprise Architecture.

In a recent Forrester survey of business architecture activity in organisations globally, 63% of respondents said that Enterprise Architects are leading their business architecture initiatives and 17% of initiatives are led directly by the Business. You usually find that with a less mature EA function, or where no EA function exists, Business Architects are found in other IT units, where they are focused on project-level or business unit (BU) level business architecture. So, it is also the scope of the Business Architecture that determines where Business Architects can be found in the organisation, with a trend for moving towards an Enterprisewide Business Architecture (as shown in diagram below).

Now let's ask why do we need Business Architecture and why is it so important to organisations? There are a number of reasons, including business insight for improved business decisions, process improvement, and IT investments, and Business and IT alignment. But, from my perspective as an Enterprise Architect, I believe that Business Architecture can play a significant part in closing the communication gap between IT and the Business. Using the right set of Business Architecture tools and techniques, an Architect can work collaboratively with the Business to develop common views of how the business fundamentally works. This not only raises the level of understanding and improves the relationship between business and IT, but provides a sound platform for the design of effective solutions.

Traditionally, IT change has followed from the analysis and improvement of a business area, but with Business Architecture its possible to design and improve systems concurrently with the business analysis and design. Business Architecture allows you to first develop direction and options for both the business and IT, followed by concurrent design and implementation of business and IT changes based on common views.

Next time, we'll take a look at what type of views make up a Business Architecture, and what methods and modelling techniques exist to help you develop a Business Architecture.

The King is dead. Long live the King!

The evidence is damning. IT is failing to meet the needs of the Business. The business does not trust IT, and it's gradually taking control of technology itself, more and more. IT must change or be left behind......

An ISACA study last year, "Changing Business Needs and Unmet Expectations Are Leading Causes of Technology Project Failure", revealed that nearly half of the Organizations surveyed have ended technology projects prematurely, with the top two reasons being that business needs had changed (29.9 percent) and the project did not deliver as promised (23.4 percent).

In the article, 'IT Doesn't Matter' (Harvard Business Review, May 2003), Professor Nicholas Carr argues that technology evolves so rapidly that IT will become a commodity, and no company can differentiate itself with a commodity. He concluded that the way you approach IT investment and management will need to change dramatically.

In the MITSloan article (Fall 2007, Vol.49 No.1), "Avoiding the Alignment Trap in Information Technology", they survey 452 companies and found a pattern to IT disappointment and failure in two clear tones: general ineffectiveness at bringing projects in on time and on budget, and ineffectiveness with the added complication of alignment to an important business objective - which they called the 'alignment trap'.

In "The Business-IT Expectation Gap" (Alex Cullen, 7th Nov 2008), a Forrester survey of 600 business executives reinforces what many IT executives may sense: While technology is very important to firms, IT is not expected to meet, nor does it succeed at meeting, the technology needs of the business. In "Closing The Business Technology Alignment Gap", Forrester Leadership Boards CIO Group discussed the challenge to IT's role from this recent survey, and identified the following gaps:

• Business Execs have high expectations of technology, but lower confidence that IT can deliver to these expectations
• Business does not perceive that IT is aligned around business' priorities
• Business considers several sourcing alternatives to IT

In this report, Forrester makes a number of recommendations including that business and technology planning are done together, move to a "collaborative work model" where some IT skills are embedded within business organisations, create Centres of Excellence for business change skills, and separate "business enablement" functions from IT delivery and operations. The last one of these recommendations highlights a key trend in Enterprise Architecture, where EA, or sometimes just Business Architecture, live outside of the IT organisation, and are part of the Business enablement function.

So, where does this leave IT, how should it change, and who is best placed to help guide us into the new world.

Some ideas can be found in the new book "Business/IT Fusion", where Peter Hinssen defines 'Fusion' as the blending of IT into the business. No longer treating IT as a supplier but completely integrating IT into the business. He says that Fusion will allow companies to focus on technology-enabled innovation, instead of just on the commodity savings potential of technology.

As Web 2.0 technologies are taken on by the Business, we are moving to a world of Enterprise 2.0. And as this technology advances and merges into the Business world, we will get new business models that bring innovation through technology, this is the world of Business Technology. Forrester predicts, in "Business Technology Defined" (7th May 2007), that over the next five years business will become so deeply embodied in technology, and the technology so deeply embedded in the business, that IT will need to be managed quite differently. And two years into that prediction, we're already seeing its impact.

In order to survive this new world you need professionals who can understand both the business context and the technology context, and they need to be able to show how the technology can best be used to enable and bring value to business models. Enterprise Architects are in this unique position, and already have some of the tools and methods required to deliver efficient and flexible IT solutions. But how do they ensure that these solutions are most effective for the business? Traditionally we have captured requirements from the business, and delivered solutions using IT's interpretation of what the business wants. Enterprise Architecture and Agile methods have brought us improved ways of working with the Business, but are these fit for the future world where the Business will take the lead on Technology?

As Enterprise Architects, we often preach about 'alignment' with the business, but that often feels like we are playing catch-up with the business and innovation is constrained to the scope that the business has already determined and set for IT. Surely there's a better way.

The answer lies in the EA domain of Business Architecture. The methods and tools that Business Architects need to design business models within an Enterprise Architecture context are critical to being able to work collaboratively with the business and deliver effective Business Technology.

In this blog, I will explore different Business Architecture methods and tools, modelling techniques and views, that you will need to be armed with as we enter the new world of Business Technology. I'll also look at the latest research and thought leadership in this area, providing you with my own view on how this may all come together.