Skip to main content

Author: Daniel Lambert

The Art of Measurement and Business Architecture

Building a Business Architecture model without measuring any of its key elements is a pure waste of time.

This article examines the need for strategic and tactical measurements, how to have effective measurements (KPIs) in place, presents various measurement diagram examples, and finally, names two sources of KPIs lists for various industries.

lambert 031417 v1

The Need for Measurement

Business Architecture will only contribute in driving Information Technology (“IT”) and Business Alignment if key business and IT stakeholders promote a “metrics-driven behavior (devising KPIs and incorporating them into the performance appraisal process).” Failure of Business Architecture initiatives and project is often the fact that C-level management hasn’t taken the time to set the Key Performance Indicators (“KPIs”) properly, as mentioned in Jason Bloomberg’s article .

KPIs can be defined at all levels of a business architecture model, including objectives/strategies, capabilities, value streams, organizations, initiatives, stakeholders, products/services, information, physical and IT assets, requirements and processes and especially all the actions and relationships that link the various parts of a business architecture together.

Some business strategies may truly be ill-advised and extremely risky. Showing the difference between strategies using chosen KPIs is what differentiates the best enterprise/business architects from others. Good business architecture will allow identifying the gaps between the current architecture and future state options by comparing architectures against KPIs and quantify the risks, using impact analyses and decision trees among others, as indicated in an article written by Tim O’Neill.

lambert 031417 v2

Measuring Effectively

The set of possible measurements for Business Architecture is very large since Business Architecture is the link between strategy and execution. Business Architecture measurements can be grouped into strategic, tactical and governance values.

Strategic Values

Business Architecture is the missing link between strategy and execution. KPIs for Strategic Values should stay focus on measuring some cohesive business goals, including business strategy execution progress measurements, business culture index(es), productivity, business communication effectiveness, business growth opportunities, and cost structure optimization.

Tactical Values

At a tactical level, the purpose of practicing Business Architecture is to improve the efficiency of your organization’s operations. Measurements of efficiency, costs, time will vary based on the nature of your organization’s business. 

Governance Values

Governance is the other key area where Business Architecture can deliver value, by determining costs variances, examining detailed impact analyses and establishing balanced scorecards associated with risks.

lambert 031417 3

Defining measurements/KPIs can be challenging. Good KPIs must have a target value and a way to be accurately measured and reported. Ideally, good KPIs should include the following characteristics, as mentioned by John Parker :

Aligned with the specific organization’s vision, strategy, and objectives.

Optimized—The KPIs should be focused on providing organization-wide strategic value rather than on non-critical local business outcomes. Selection of the wrong KPI can result in counterproductive behavior and sub-optimized results.

Measurable—Can be quantified.

Realistic—Must be cost effective, coherent with the organization’s culture and constraints and achievable within the given timeframe.

Attainable—Requires targets to be set that are observable, achievable, reasonable, and credible under expected conditions as well as independently validated.

Clear—Clear and focused on avoiding misinterpretation or ambiguity.

Understood—business and IT stakeholders and relevant organizational units should know how their behaviors and activities contribute to achieving the KPI.

Predictive—The KPI may be compared to historical data over a reasonably long time so that trends can be identified.

Agreed—All stakeholders should agree and share responsibility for achieving the KPI target.

Reported—Regular reports are made available to all stakeholders and contributors, so they know the current state of the business architecture model element and take corrective action if required.

There are numerous ways to design measurement/KPIs diagrams. In this article, you will find 5 diagrams, including the 2-dimensions pie and donut charts, the 2 or 3 dimensions bar chart, the 3 dimensions bubble chart and finally the 4-dimension radar chart.

lambert 031417 4

Sources of KPIs

There are numerous sources of KPIs lists. It’s easy to get lost. In the Business Enterprise Architecture world, I will limit myself to two. First, there are the KPIs lists for each of the four IT Values Streams defined by the OPEN Group; especially the KPI list regarding the Strategy to Portfolio IT Value Stream . Second, there is the APQC’s Process Classification Framework that contains hundreds of processes , including detailed definitions and thousands of key measures for numerous industries. In particular, the APQC’s Process Classification Framework includes a section about developing and managing Business Capabilities

Definitions and Key Measures that can be very useful for Business Architecture . As for the latest version of BIZBOK, surprisingly it often mentions the necessity of measurements/KPIs but does not elaborate further than that.

lambert 031417 5

Conclusion

This article has examined the need for strategic and tactical measurements, how to have effective measurements (KPIs) in place, presented various measurement diagram examples, and finally named two sources of KPIs lists for various industries.

Combining Agile Methodologies and Business Architecture

Agile methodologies and business architecture may seem to be two conflicting approaches to delivering software initiatives at first glance.

In reality, they are very complimentary. Agile methodologies get you to execute projects at a much higher pace. Business architecture makes sure that you are not forgetting anything important and looks at all impacts of a project. An Agile project can be executed with lower risk and higher odds of success if it is bulletproofed using business architecture at the same time. Two presentations made at various Business Architecture Guild events are eloquent about that subject:

• Business Architecture & Agile Methodologies made by Whynde Kuehn, Alex Randell, Eric Shayne Elliott, Francis Fons, and Jeffrey Wallk among others.

• Experiences Linking Business Architecture with an Agile/Lean Development Method made by John Baker.

Agile Methodologies

The Agile Manifesto , explains very well the philosophy that is behind the various Agile methodologies used in IT departments to develop relevant software rapidly.

Agile methodologies focus more on the following:

  • Individuals and interactions rather than on processes and tools;
  • Working software rather than on comprehensive documentation;
  • Customer collaboration rather than on contract negotiation; and
  • Responding to change rather than on following a plan.

Lambert 1

As shown in Diagram 1 above, Agile methodologies can involve the use of various methods. One of these methods is called the Scrum Software Development Method with roles, workflow, artifacts, and sprint backlog among others. John Backer shows a typical Scrum lightweight project management process in Diagram 2 below.

Lambert 2

Another Agile method often used is called the Iterative and Incremental Development Method as shown in Diagram 3. This method includes in iteration the following steps: planning, requirements assessments, analysis & design, implementation, testing, evaluation.

Lamber 3

Before executing any Agile methodology, making a requirement breakdown is preferable, as shown in Diagram 4 below. Unelaborated stories need to be estimated and roughly drafted. Serious ones should then be regrouped by high-level requirements, which are enumerated and ranked usually based on business strategies and tactics – where business architecture can play an important role.

Lambert 4

As pointed out in Diagram 5, Agile methodologies are not an excuse to stop producing documentation. Agile is not an opportunity to eliminate planning. Neither is Agile open season for uncontrolled changes or continuous growth in a project’s scope. Finally, Agile methodologies are not about blindly following a set of “best” practices that can be changed from project to project. In brief, Agile is not a reason for not building and maintaining your business architecture from one initiative to another. If, while practicing Agile methods, you don’t know the overall destination and communicate it clearly then are you just making things up as you go along, potentially creating a fragmented mess. Hence the necessity of Business Architecture!

Lambert 5

 

Business Architecture

Business Architecture is all about building capability, value, organization, stakeholder, information, asset, product, strategy and initiative maps and describing the relationships between them that are specific to your business, as shown in Diagram 6 below. Once in place, Agile experts can use their business architecture model to link their requirements and processes to capabilities and values among others to enable full impacts analysis to lower risk and make sure that there are no surprises while delivering a project/initiative/program.

Lambert 6

According to The Open Group , Business Architecture is part of Enterprise Architecture as one of four architecture domains that constitute Enterprise Architecture. Yet, Business Architecture does not need to be as complicated as Enterprise Architecture tools often suggest. These tools use traditional stages of design, build and implementation. Project management best practices work well with this approach, and it is highly comfortable. However, this approach is lengthy, costly and to cap it all by the time you get to implementation the world has moved on. You potentially end up having the wrong solution because your speed to change is so poor. It is, therefore, understandable that Agile purist cannot warm up to the heavy Enterprise Architecture approach.

Business Architecture, in contrast, is much lighter than Enterprise Architecture. Getting setup for the first initiative(s) may take between 2 and 6 months by importing existing data from other systems already in place in an organization, by building the first levels of capabilities, organizations, information and relevant value streams maps and by finally describing relationships between components/elements of your business architecture model that reflect your company’s reality. Once in place, updated at regular intervals and if made available to the IT community and key stakeholders, your business architecture model will have positive and rapid effects for each additional initiative helping business analysts build well-defined user stories and requirements for which Agile methodologies can be used for better and quicker execution.

Blending Agile Methodologies and Business Architecture

As explained at much greater length in this article entitled “Align your Requirements to Corporate Strategies Using Business Architecture,” Agile experts should build their user stories as shown in Diagram 7 below to make sure that all possible impacts are known and taken into account before delivering an initiative. This technique enables to trace the requirement logic from its basic components, like capabilities, stakeholders, value, information and process. This way, the focus is placed on the strategy and origin of the requirements via business architecture, not simply back to a project artifact.

Lambert 7

As pointed out by Whynde Kuehn, Alex Randell, Eric Shayne Elliott, Francis Fons, and Jeffrey Wallk , by knowing the business and having taken the time to articulate its value streams and capability maps, you can now have immediate and reusable impacts in the following:

  • Requirements/Grooming: what areas must we understand for development or process changes,
  • Prioritization: what is important, what capabilities may not yet be in place, and
  • Scrum/Release planning: better understanding of dependencies and groups of stories/requirement(s) that make up a capability.

Like it or not, Agile Methodologies will gain in its outcome if they blend in their process the use of a regularly updated business architecture model that is made easily available to the IT department of an organization.

 

[1] The Business Architecture & Agile Methodologies made by Whynde Kuehn, Alex Randell, Eric Shayne Elliott, Francis Fons, and Jeffrey Wallk among others on September 17, 2014 at the Business Architecture Guild Workshop Event in Austin TX.

[1] Experiences Linking Business Architecture with an Agile/Lean Development Method made by John Baker, Business Architect at MasterCard on March 13, 2013 at a Business Architecture Guild Innovation Summit event in Washington DC.

[1] The Agile Manifesto is described on this webpage.

[1] The Scrum Software Development Method Wikipedia webpage.

[1] The Iterative and Incremental Development Method Wikipedia webpage.

[1] Top Diagram in the article entitled “Align your Requirements to Corporate Strategies Using Business Architecture” written by Daniel Lambert

[1] From this webpage.

[1] Figure 5 in the article entitled “Align your Requirements to Corporate Strategies Using Business Architecture” written by Daniel Lambert

[1] Page 13 of the Business Architecture & Agile Methodologies made by Whynde Kuehn, Alex Randell, Eric Shayne Elliott, Francis Fons, and Jeffrey Wallk among others on September 17, 2014 at the Business Architecture Guild Workshop Event in Austin TX.

Align Your Requirements to Corporate Strategies Using Business Architecture

In an article entitled “Business Analysts and Business Architecture” published earlier this year in the Business Analyst Times, I got a comment from Duane Banks, a Business Analyst at United. I had shown a graphic were Business Analysts were only involved in some operation planning and mostly in delivery and execution of initiatives. He said the following:

lambert1

With Business Architecture, Duane and many other Business Analysts are right to assume that the scope of the perspective of a Business Analysts can be much broader than traditionally perceived by the IT industry. With Business Architecture, Business Analysts can now be involved in the strategic, operational and even marketing planning on top delivery and operations of projects, as shown in Figure 1 below.

lambert2

Business Architecture Propagating Corporate Strategies to IT Professionals

BABOK® Guide v3 is very clear about this. Business Architecture is one of 5 new perspectives that a Business Analyst should take into account while managing its business requirements. In the Business Architecture perspective, reference models are listed instead of methodologies or approaches. They are called meta model, which can include up to 11 different maps, as shown in Figure 2 . No single part of this meta- model should be assessed or altered in complete isolation from the rest of the model.

lambert3

This diagram takes into account Requirement Mapping and Process Mapping and allows it to be linked to other maps. To execute the business strategies included in business architecture, you need to include requirements and business processes. If the meta model of a corporation’s business architecture is well defined, you can even easily link a requirement among thousands to one or a few processes among again thousands of processes, as in the telco world for example. In brief, a good Business Architecture Model will enable the Business Analysts, the Process Experts and the IT/Software/Enterprise Architects in a large corporation to stop working in silos and start working together, as shown in Figure 3.

lambert4

Deriving Business Requirements from Business Architecture

Let’s now take a closer look at requirement mapping within Business Architecture and show how both disciplines can work in pair.

Requirements will usually be linked to a value stage and/or capability. In Figure 4 below extracted from the BIZBOK Guide , let’s take a look at this Value Stream, entitled “Acquire Loan”, made of Value Stages in white.

lambert5

 If you take a closer look on how to «Approve a Loan» in this Value Stream, you need to «Validate an Application» beforehand and «Issue a Second Approval» afterward. When you «Approve a Loan», the additional Routing Map or Process Map occurs with 9 steps in this case. It involves stakeholders like the client, the loan administrator, the loan officer, and the contract officer. It also involves the following information concepts: terms of the loan, loan agreement, and minimal monthly minimal payment of loan. It finally involves the “Agreement Structuring” capability and its children “Agreement Terms Management”, which enables the Value Stage “Approve Loan”.

This finally leads to a User Story which could be as short as this one: “As a Loan Officer, I want to set the terms of the agreement to reduce the monthly minimal payment.”

lambet6

To avoid confusing anyone, Figure 5 shows how a User story could be written using Business Architecture elements that are made available to Business Analysts by Business Architects and their Business Architecture meta model. The user story is longer, but it includes every necessary element of the business architecture. Some of these elements are Capabilities, Information, Stakeholders, a Process, and Values. The count is 14 elements, but it could have been higher if Figure 5 had included the one or two software application(s) in the Asset map that would need to be modified to fulfill this requirement. Finally, it could also have included specific elements of the Strategy Map.

Impacts of Business Architecture on Business Analysts

As you can see, Business Architecture is not just hype. It can assist the Business Analysts in its daily work as shown in this example. There are at least 4 impacts of Business Architecture on Business Analysts:

  1. Business Architecture enables to build more relevant user stories and business cases using appropriate business strategies and precise vocabulary before they get approved and funded as a project,
  2. Business Architecture enables clearer requirements definition and requirements validation,
  3. Business Architecture enables to scope, frame and categorize requirements based on business strategies, and
  4. Business Architecture avoids requirement duplications across business units and departments.

 

 

  1. Article entitled “Business Analysts and Business Architecture” written by Daniel Lambert and published in Business Analyst Times on March 16, 2015.
  2. BABOK® Guide v3 is available here for IIBA members.
  3. Figure 2 is extracted from the LinkedIn article “Increase your Transformation Success Rate with Business Architecture” written by Daniel Lambert published on LinkedIn on April 21, 2015.
  4. Figure 4 in this article is Figure 3.8.3 extracted from the BIZBOK® Guide on page 331. To access the BIZBOK® Guide, you need to become a member of the Business Architecture Guild.

Business Analysts and Business Architecture

Business Architecture: from Chaos to Processes

Large corporations try to make sense from chaos that surrounds them by understanding their environments, finding rules of thumb, implementing robust, repeatable, replicable processes and ultimately optimize their profits. This reality gets to be more complicated with large corporations. It involves numerous professionals within the corporation that do not naturally communicate with each other often creating duplicated efforts or even worse confrontational efforts. Furthermore, new unresolved business challenges emerge frequently for which a corporation has yet to find valid rules of thumb and that can even make their current rules of thumb obsolete. This is where the business architecture discipline comes into play in result oriented corporations.

dlambert img001 March17

As shown in Figure 1 above1, business architecture techniques makes it possible to make sense of chaos and find heuristic rules of thumb to develop news algorithms to make robust and repeatable formulas and processes executed afterward by enterprise architects, program managers, project managers and business analysts in their various business units. Motivation models, cohesion planning, cross functional capabilities mapping, value maps, business strategy mapping and other techniques makes it possible for business architecture team within an organization to find heuristic recipes, which can afterward be used and communicated to enterprise architects, project managers, program managers and business analysts.

Why Business Architecture?

Due to new emerging business challenges, corporate strategies are changing more and more rapidly triggering each time one or several new business architecture initiatives that need to be addressed promptly. These initiatives may vary a lot from a new product offering in the marketplace to a business unit restructuring or the integration of people, processes, capabilities, technology and culture during a merger and acquisition, etc. As shown in Figure 2 below2, the business architecture discipline is involved in the strategic, marketing and operational planning of any new corporate initiative. Each business architecture initiative then needs to be delivered and executed by enterprise architects, program managers, portfolio managers, project managers, solutions architects, solutions software developers and of course business analysts according to plans coming from corporate executives. This is usually a big challenge, since only 25% of change management initiatives are successful over the long term according to a 2013 study made by Towers Watson3.dlambert img002 March17

There are several reasons why this failure rate is so high:

  • Too often business goals set by corporate executives are not realist,
  • The corporate executives are not involved in the daily activities required to make business changes happen, and
  • Business strategies are not well communicated throughout all involved functions of every business units to insure success.

In brief, business architecture initiatives are too often not laid out properly in a common language and even less clearly communicated in details to key stakeholders, enterprise architects, project managers and business analysts. This is why only 20% of respondents to an IBM 2014 Survey considered themselves successful in managing change within their corporation4.

Business Architecture: the Link Between the Corporate Executives’ Business Strategies and Business Analysts

Yet, there are tools out there that can make it easy for Business Architecture teams within a large corporation to communicate a common message while executing business architecture initiatives that will relate to corporate executives, enterprise architects, project managers and business analysts to avoid working in siloes.

For the Information Technology (“IT”) department and their business analysts, business architecture is the elaboration of what the business people are trying to do. It might picture process flows, information flows, corporate goals list, business strategy mappings, capabilities diagrams, requirement planning, product mapping, or simply the currently popular competencies within the corporation. Business architecture needs to be something that business managers can view, have approved and that can afterward be shared with business analysts, project managers and enterprise architects. As mentioned in BPTrends5, Business architecture should not be an abstraction created by the IT department and claimed to be derived from conversations with business managers.

Business architecture tools include possibly business architecture modules part of Enterprise Architecture software applications like Troux Enterprise Portfolio Management, MEGA Enterprise Architecture, Aris Business & IT Transformation or more specific and user-friendly software tools for business architecture that allow easy publishing of a corporate’s business architecture model in print or on private Webpages using browsers6. Business analysts and IT managers can use these tools daily to handle their IT requirements. They can easily consult their corporation’s business architecture model on the Web to have the most accurate content relating to their activities and make sure that their IT projects are in line within the organization’s business strategies and at the end increase the odds of success in their own initiatives.

Don’t forget to leave your comments below.

Footnotes:

  • 1Graphic made from slide 43 in the slideshow entitled “Driving your BA Career – From Business Analyst to Business Architect” made by Craig Martin on Sept. 30, 2014 and from the book entitled “The design of Business”, written by Roger Martin in the Harvard Business Press in 2009.
  • 2Graphic made from slide 17 in the slideshow entitled “Driving your BA Career – From Business Analyst to Business Architect” made by Craig Martin on Sept. 30, 2014.
  • 3Source from the article entitled “New Study Explores Why Change Management Fails – And How To (Perhaps) Succeed” written by Victor Lipman in Forbes on Sept. 4, 2013.
  • 4Source: Executive report from IBM’s Global Business Services entitled “Making change work …while the work keeps changing. How Change Architects lead and manage organizational change” and written by By Hans-Henrik Jorgensen, Oliver Bruehl and Neele Franke.
  • 5To find out more, read this article entitled “Who needs Business Architecture”, written by Paul Harmon in BPTrends on Dec. 13, 2014.
  • 6To find out more about one specific and user-friendly tool for business architecture, read this article entitled “View into the Business Architecture Practice of a Renown USA Federal Agency” published on LinkedIn on Nov. 5, 2014.