To embrace change in the most effective and efficient manner means that the agents of change must operate harmoniously. These agents of change include the portfolio, programme and project managers and the architects who strive to better the organisation’s capabilities to meet the external demands of customers, shareholders, regulators and society in general.
In an Olympic year a sporting analogy seems appropriate. For a rowing crew to fulfil their potential, each and every crew member has a well-defined part to play; they each have a specific seat in the boat. Their training regime is general and specific; general to hone their physical and technical abilities and specific for their position in the boat.
However, as Ralph Waldo Emerson (author, poet, and philosopher) said: ‘No member of a crew is praised for the rugged individuality of his rowing.’Each member of the crew must row in time, applying similar and complimentary forces to achieve a balanced and optimal performance - as a team. It is the collective efforts of all the crew that yields the greatest rewards. And the same is true with business change agents.
Business architecture and the portfolio, programme and project managers are members of the same crew and they occupy different seats in the boat. Business architecture aims to define what the organisation should look like and how the elements of which it is comprised (i.e. its capabilities, processes, locations, employees, systems and so on) should be best arranged.
This is complementary to portfolio, programme and project management, the primary objective of which is transitioning the organisation from its current state to the desired (defined and agreed) future state. Pivotal to achieving this objective is a specific and unambiguous description of the desired outcomes and outputs for members of the programme and project board who are responsible for the delivery.
Alignment with other change initiatives is made easier if the same language is spoken and common views / viewpoints are taken across the change portfolio. This description should provide sufficient insight to enable the construction of a viable work breakdown structure and to guide the detail specification, delivery and deployment that follows.
The description is the architecture of the business. This description should exist at all levels of the business, although the level of detail will vary depending on the level at which the architecture is being defined. So the business architecture is a way of describing change consistently across programmes and projects. This fosters the reuse of assets (e.g. capabilities) and also enables traceability to the strategic architecture (including the organisation’s strategic objectives).
However, many projects proceed without creating outputs that are aligned with the strategic objectives of the organisation; they focus on the needs of specific capabilities or functions (departments) or even prominent individuals. Business architecture should form a part of every programme and project to ensure that new capability is aligned on a consistent and impartial basis with strategic objectives.
One standard that attempts this is the UK Government‘s Managing Successful Programmes (MSP) standard. It identifies the definition of a‘blueprint’along with the business case and benefits case as a pivotal activity in defining a programme. This blueprint is by any other name a description of the business architecture. This programme-level business architecture is used to define:
- what the future state will look like;
- what the intermediate states will be;
- what the current state is.
It is developed in parallel with the business case and benefits profile, and is used to determine the projects within the programme that are required to create and deploy the future state.
Although MSP indicates that the blueprint is essential, it also states that it is the programme manager who is responsible for creating it. However, while the programme manager may, in name, be responsible for the blueprint, it is an architecture product and should be produced by an architect.
A primary (but not sole) reason for this is the relative perspective between programme / project managers. Programme / projects managers focus on relatively short-term deliveries and they are often required to compromise on the longer-term strategic objectives to ensure delivery to time and cost. Architects, on the other hand, focus on the medium to longer term and can be inclined to resist deviation from the higher-level architectures. This can create tension, albeit a healthy one.
A primary activity of business architects is the communication of the organisation's business architecture, including its goals, objectives, benefits and so on. That communication should support the activities of programme and project managers.
Programme and project managers and business architects working collaboratively should foster a win-win partnership for the benefit of all stakeholders (and not just the programme/project managers and architects). And as programmes and projects get into their stride, business architects should be working hand-in-hand with programme and project managers to reaffirm the desired outcomes, with responsibility to bring to bear the larger strategic picture.
Business architecture and change management are complimentary disciplines and both share many of the same challenges, most notably step-change improvements in the speed and agility required to deliver change in today’s fast-paced business landscape.
However, there are overlaps between the disciplines and these can lead to confusion and, ultimately, friction amongst practitioners. Nevertheless, the friction generally relates to a lack of clarity of role (and the intent of the role) rather than to the defending of any territory. After all, both disciplines strive for the same outcome ... the advancement of the organisation’s capabilities.
So what does the future hold? Over the coming years, business architecture practices will evolve their value proposition and establish differentiation, delineation and integration with other practices and disciplines. The answer to the question: ‘How can business architecture help business strategy and planning?’ will become clearer, as will the answer to the question: ‘How does business architecture relate to portfolio, programme and project management?’
Furthermore, each discipline comes with its own ‘tool kit’ - the methods and techniques (such as MSP and Prince2 for programmes and projects, and TOGAF and the Zachman Framework for Architecture). These tool kits also need to be harmonious - although there is still work to be done to achieve that.
Business architecture is still an evolving discipline; it is just starting to stand on its own two feet. But it will not be able to deliver value in its own right; value can only come through collaboration with those who are responsible for delivering change - the agents of change who occupy different seats in the boat; working harmoniously offers medal-winning potential.
Happy rowing...
About the author
Jonathan Whelan is an established business architect who has over 25 years’ experience in a variety of change-related roles within leading organisations. As well as having considerable practical experience, Jonathan is a Chartered Engineer and a Fellow of the BCS, The Chartered Institute for IT. Jonathan also writes on business technology issues and opportunities and is the author of numerous books, including email@work (2000), e-Business Matters (2000) and Business Architecture - A Practical Guide (2012).
