written by Daniel Lambert in LinkedIn
Only 25% to 30% of business transformation initiatives are successful over the long term according to various studies made by Towers Watson , Harvard Business Review , McKinsey & Co  and others. One of the reasons why the transformation success rate is so low for so many transformation projects is the fact that business architects, enterprise architects, business analysts, project managers, process managers and product managers work in silos. Thus they cannot take into account easily the output of their peers and communicate their work between each other in an orderly fashion. This makes it difficult for any reconciliation between different disciplines which yet all have the same ultimate objective of transforming their businesses successfully to strive in a highly competitive environment.
After a brief overview of Business Architecture’s, BPM’s and Requirement Management’s definitions, this article will explain how the convergence of Business Architecture, BPM and Requirement Management can help align your corporate strategies. It will also show a pragmatic perspective on how Business Architecture could easily become the practice allowing top level stakeholders, process experts, requirement people and enterprise architects of a same company to stop working separately in silos and achieve their tasks knowing what others are doing to enable higher synchronization between everyone.
Before delving into the heart of the subject, it is important to take a look at the various disciplines that are involved in delivering strategic initiatives for the business.
Business process management (BPM) is a field in operations management that focuses on improving corporate performance by managing and optimizing a company's business processes. BPM is often described as a "discipline involving any combination of modeling, automation, execution, control, measurement and optimization of business activity flows, in support of enterprise goals, spanning systems, employees, customers and partners within and beyond the enterprise boundaries .” Process people involved in BPM are usually Business Analysts, Lean or BPM consultants, who are involved in redesigning business processes and who would operate any Business Process Center of Excellence established in an organization.
Requirements management is the process of documenting, analyzing, tracing, prioritizing and agreeing on requirements and then controlling change and communicating them to relevant stakeholders. It is a continuous process throughout a project, a product (or a service) development.  Requirements people involved in Requirements management are usually project managers, product managers and program managers.
3- Convergence with Business Architecture
Without knowing the most current business strategies, the odds of defining and meeting requirements and optimizing processes successfully are very low. This is where Business Architecture comes into play. Business architecture is defined as “a blueprint of the enterprise that provides a common understanding of the organization and is used to align strategic objectives and tactical demands. " People who develop and maintain business architecture are business architects or sometimes enterprise architects. From Capability, Value, and Strategy maps, business architects capture business strategies from key stakeholders and then communicate it to Business Analysts, Lean or BPM consultants by linking Value Streams to detailed Processes (Process maps) or to project managers, product managers and program managers by using product and requirements maps. Furthermore, Business Architecture, when well executed, can even insure that the requirements and process experts communicate with each other constructively.
4- Business Architecture and BPM – Differentiations and Reconciliation
Business Architecture and BPM should not be confused. They are very different approaches in fine tuning an enterprise. As pointed out by a Business Architecture Guild whitepaper, entitled Business Architecture and BPM – Differentiations and Reconciliation , business architecture is more about how “we separate the concern of what we do (capability), from who does it (organization), from how value is achieved (value Stream), from how it’s done (process), from the information that’s needed, from the systems that are used, and so on. These individual concepts and relationships are stored and managed in a knowledge base, which is built incrementally. As for BPM, it was born from the Business Process Reengineering (BPR) movement and emerged as an operational approach with its standardized process languages “that generalizes and redefines the outcome of the set of related activities to be the realization of business goals and objectives.”
Section 3.4 of the BIZBOK guide  explains how business architecture and BPM are linked using business architecture value maps. Each value stage that composes value streams can be linked to one or more process elements of Process maps derived from BPM. The reverse is also true. Each process element of a Process map can be linked to one or more value stage. Linking Value Stages to Process elements from BPM Process maps results in numerous advantages, including the following:
- “Business architecture/process mapping establishes insights in process redundancy across business units and organizations”,
- “Business architecture provides a top-down business perspective for planning process related work, changes, and improvements”,
- “Business architecture/process mapping delivers insights into business transformation as it relates to value delivery”, etc.
5- Business Architecture and Requirements Management
As explained in the Business Architecture Guild whitepaper entitled “Leveraging Business Architecture to Improve Business Requirements Analysis ”, requirements management is broken down into 4 primary phases: planning, elicitation, analysis and solution design. Outputs of requirement management include specific statements and rules essential to achieve a defined targeted state using multiple levels of detail. Requirement management alone is problematic. 70% of software projects fail due to poor requirements with an associated rework spending of about $45 billion annually mostly because organizations do not commit to an institutionalized priority around a value-centric customer/user focus approach leaving value mapping concepts totally out of the picture. 
Section 3.8 of the BIZBOK guide  explains how business architecture and requirements management are linked using business architecture value, information and product maps, by using the Business Architecture Frame of Reference enabling business requirements traceability across multiple business perspectives (figure 3.8.1). “Starting with the customer/user perspectives that will always drive the intended outcome, requirement management must consider multiple perspectives and capabilities that will shape and ultimately define those final conditions that must be present to deliver the intended business outcome.”
6- Business Architecture – A Pragmatic Perspective
In a pragmatic perspective, most corporations have implemented BPM, Requirements and Enterprise Architecture software tools in silos. There is very limited interaction between these 3 different types of systems. There is a need today for an equivalent system focused on Business Architecture allowing not only capability and value maps, but also a multitude of other maps, including process and requirements mapping derived from the BPM and the requirements disciplines.
The landscape of software application tools to execute BPM and Requirements Management is mature. Among BPM tools, Gartner  mentions the following companies in its top tier IBM, PegaSystems, Progress, Apian and Software AG. Within the Requirements Management space, vendors are also numerous. According to Butler Analytics , they include among others TechExcel, IBM, HP, Borland, CA and a bunch more. Neither BPM tools nor Requirement management software products offer any descent business architecture features. Furthermore, no BPM tools allow to link process elements to requirements elements. The reverse is also true. No Requirements Management tools allow to match easily requirements elements to process elements. This is despite the fact that on top of making sure to align requirement and process mapping to top level business strategies using business architecture, the odds of success of a transformation initiative will increase significantly if the process people can match their process elements to requirements and/or the requirements people can match their requirements to process elements. This fact is also the case of vendors that offer a product for each practice. Even the products from the same vendor do not allow to link easily process elements to requirements.
The situation is very similar with Enterprise Architecture tools. Most EA tools listed on the Gartner Quadrant for Enterprise Architecture Tools , like MEGA, Troux, Software AG, IBM, etc., have a business architecture module. As pointed out by Atul Bhatt in the Architecture and Governance Magazine  in 2013, “While the related fields of Business Process Management (BPM) and Business Rules Management (BRM) have fairly mature tools, generic Business Architecture tools are still not there in functionality, usability, and maturity. At best, the current Enterprise Architecture tool vendors (Sparx Systems EA, TROUX, etc.) have been extending their existing tool sets to cover some of the BA aspects.” Still today, enterprise Architecture tools cannot take into account easily process mapping and requirements mapping while tying it to business strategies using business architecture.
In brief, Process experts, Requirement people and even Enterprise Architects tend to work in silo basically ignoring each other’s work, often limited by their respective tool.
This could change soon with the arrival of specific easy to use business architecture tools, like IRIS Business Architect , that follow the BIZBOK guide principles to take into account not only capability and value maps, but also other maps, including process and requirements mapping. Such tools offer the ability to link all the content together, allowing for advanced analysis. With tools like IRIS Business Architect, Business Architects in 2015 can now finally stop the silo effect within corporations and tie the knot between key top level stakeholders, process experts, requirement people and enterprise architects to insure that they can work in respect of each other while aiming the same ultimate objective of transforming their corporation successfully to keep striving in a highly competitive environment.
Read more here.
 Source 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.
 Source from the article entitled “What Customers Want from your Products” written by Clayton M. Christensen, Scott Cook and Taddy Hall on Harvard Business School’s web site; January 16, 2006.
 Source from the article entitled “How to beat the transformation odds” published in McKinsey & Co Insights and Publications in April 2015
 Source from the article entitled “One Common Definition for BPM” written on Thinking Matters on January 27, 2014.
 Source: Requirements Management definition in Wikipedia.
 Source: Business Architecture definition in the BIZBOK Guide (version 4.1.141028L) on page 5 of 523 pages.
 Source from the whitepaper entitled “Business Architecture and BPM – Differentiations and Reconciliation”, written by Lloyd Dugan and Neal McWhorter (with the assistance of the following Business Architecture Guild reviewers: Sue Alemann, Yojana Ganduri, Whynde Khuen, James Rhyne, Mike Rosen, William Ulrich, Elaine Wong) and (with the assistance of the following BPM Community reviewers: Paul Buhler, Roger Burlton, Tom Dwyer, Peter Fingar, Jim Sinur, Shelley Sweet, Keith Swenson, Dennis Wisnosky) on October 31, 2014 on page 5 & 6 of 23 pages.
 Source from the section 3.4 in the BIZBOK Guide (version 4.1.141028L) entitled “Business Architecture and Business Process Modeling and Management” on pages 263 to 274 of 523 pages.
 Source from the whitepaper entitled “Leveraging Business Architecture to Improve Business Requirements Analysis”, written by Alex Randell, Eric Spellman, William Ulrich, Jeff Wallk and reviewed by Mike Clark, Eric Elliott and Whynde Kuehn in March 2014 on pages 2, 7 & 8 of 15 pages.
 Source: U.S. Bureau of Economic Analysis, 2008.
 Source from the section 3.8 in the BIZBOK Guide (version 4.1.141028L) entitled “Business Architecture and Requirements Alignment” on pages 313 to 326 of 523 pages.
 Source: this article about the 2010 Gartner BPMS Magic Quadrant published on November 2, 2010 on Agile Elements blog.
 Source: this article entitled “20+ Requirements Management Tools” published on July 17, 2014 on the Butler Analytic’s blog.
 Source: the article about the “Gartner Magic Quadrant for Enterprise Architecture Tools 2014” published on Mega International’s website.
 Source: this article entitled “Business Architecture – A Pragmatic Perspective” published in the Architecture and Governance Magazine on January 15, 2013.
 View additional information about IRIS Business Architect on this website .