LeveragingBusiness Architectureto Improve BusinessRequirements AnalysisA Business Architecture Guild WhitepaperAuthors: Alex Randell, Eric Spellman, William Ulrich, Jeff WallkReviewers: Mike Clark, Eric Elliott, Whynde MelaragnoDate: March 2014
Leveraging Business Architecture to Improve Business Requirements AnalysisIntroductionWith all the money and resources invested in new product development, over 80% will fail. 1That is an astonishing fact given all the information and knowledge being tracked aboutcustomers, products, competitors, and environmental factors. This level of waste would neverbe tolerated in any supply chain, yet it persists and prospers in most organizations. The numberone reason for this level of failure is the inability of organizations to link the relevancy of theirproducts to what their customer’s are trying to get done in their lives. 2“The statistics are quite alarming when it comes to new products; 4 out of 5 will fail.”The problem doesn’t stop at defining customer needs. Projects designed to deliver newproducts involving information technology also have a poor track record. There is a clear needto improve performance and delivery of software projects. Consider that 70% of softwareprojects fail due to poor requirements. The estimated rework associated with these failuresexceeds 45 billion annually. The question is – why is this happening? The answer is twofold.First, business requirements tend to lose focus on the customer; and second, the requirementslack a holistic frame of reference that enables requirements analysts to drive and tracerequirements from customer need, through strategy, and down to the solutions beingimplemented. Business architecture addresses both challenges and has the potential to turnthis figure around.“70% of software projects fail due to poor requirements with an associated reworkspend just north of 45 billion annually” 3Most organizations treat requirements management as a means towards an end for projectsand/or programs. Successful organizations tend to think about requirements management as acorporate capability and the data that is captured as a corporate asset, which can be carefullynurtured, validated, warehoused, and mined. Done right, requirements management can beused to link desired outcomes from customers and stakeholders to drive change and ensuresustainability for the organization. As the complexity of launching new products and servicesand driving continuous improvement increases, organizations are turning to businessarchitecture to help them reduce risk, costs, and cycle time.A Guide to the Business Architecture Body of Knowledge (BIZBOK Guide) 4 has helpednumerous organizations establish a business architecture framework that can be leveragedthroughout the requirements management lifecycle. The next evolution for the requirementsmanagement lifecycle is to fully incorporate this framework to maintain a customerperspective, aligned to strategies, value streams, business capabilities, and planning roadmaps.March 20142Copyright 2014 Business Architecture Guild
Leveraging Business Architecture to Improve Business Requirements AnalysisThe outcome of this alignment is an improvement in the success ratio of product-relatedinvestments.Ideally, organizations should commit to an institutionalized priority around customer focus. Thisrequires a level of commitment and discipline to create a deep understanding of whatcustomers want using a value-centric approach. The company must determine what thecustomer is trying to achieve as an end goal when they “hire” a product/service to accomplishone or more jobs? 5 By establishing a customer-focused, value-centric approach, organizationscan align their business capabilities to ensure they deliver the right products. Organizationsneed to expand their definition of “customer” to include regulatory, statutory, and businessstakeholders – investors, partners, and upstream/downstream participants – in various valuestreams and value networks. The definition of customer is broadened to include stakeholdersand consumers, since both may benefit directly and indirectly from an organization’s productsand services.Companies may feel that they lack the time and resources to establish a customer-oriented,value-centric approach, so instead they often opt to only improve process and productivity,leaving customer value totally out of the equation. This internally-focused, efficiency-orientedapproach means that little value analysis has been performed, leaving value mapping conceptstotally out of the picture. The result is an improvement in productivity, but alienation ofcustomers who ultimately move towards competitors and other options. This is fundamentallyflawed since the only way to establish customer intimacy and gain a deeper level ofunderstanding is to observe and talk with customers, which can be accomplished by modelingcustomer behavior through value mapping.As outlined in this whitepaper, positioning business requirements from a customer valueperspective, through the use of business architecture, provides a fresh approach fororganizations to drive strategy and maximize investments that increase customer satisfactionand retention, and deliver more value for their investment in business requirements analysis.Business Architecture vs. Business RequirementsA business architecture-based approach allows for increased clarity of purpose, design, andscope. A generally-accepted goal of business architecture is to provide “a blueprint of theenterprise that provides a common understanding of the organization and is used to alignstrategic objectives and tactical demands”.6Key blueprints, as defined in the BIZBOK Guide , relevant to business requirements primarilyinclude strategy maps, value streams, and capability maps, as well as organization, information,stakeholder, product, and initiative maps. The progression of mappings utilized in businessMarch 20143Copyright 2014 Business Architecture Guild
Leveraging Business Architecture to Improve Business Requirements Analysisarchitecture define strategy, value delivery, and what a business does, which then allows forthe alignment of specific project requirements.Business requirements, on the other hand, are defined by a different focus, typically manifestedas solution-oriented statements of need. A Guide to the Business Analysis Body of Knowledge Version 2 from IIBA defines a requirement as:1. A condition or capability needed by a stakeholder to solve a problem or achieve anobjective2. A condition or capability that must be met or possessed by a solution or solutioncomponent to satisfy a contract, standard, specification, or other formally imposeddocuments3. A documented representation of a condition or capability as in (1) or (2). 7It is important to note that a requirement can take many forms, such as: technical or businessoriented, functional or non-functional, high-level or detailed. Requirements, in the context ofthis whitepaper, may also include use cases, agile user stories, or other structures. Regardlessof the methodology employed by an organization, this holistic view of requirements canleverage a business architecture framework.Business requirements provide a means to consistently and methodically address gaps andlimitations in capabilities and value streams, with the result being solutions that address a widevariety of strategic and tactical business needs. All of these requirements artifacts provide astructured way to capture and warehouse the specifications used to precisely guide changes toproducts and services used to deliver value. In order to achieve this level of precision, acommitment to requirements management and the business architecture used to frame (andalign) these artifacts is required. Where organizations often go off-course, resulting in reworkor worse (delivering the wrong products and services to customers), is when the commitmentto aligning business requirements and business architecture is bypassed in favor of a quick fix.At this point, it is important to address a common misperception related to this subject. Whilebusiness architecture and business analysis share some similarities, both disciplines have adistinct purpose, multiple inputs and multiple consumers, and as such need to evolve and bemanaged as separate disciplines. The blueprints created by a business architect may be used asa framework for business requirements, as we expose further in this whitepaper. In addition,these blueprints assist executive leaders in gaining clarity of thought, making better decisions,meeting business challenges, and forming solutions to those challenges. Further, businessarchitecture blueprints are of use to strategic planning teams, portfolio managers, projectMarch 20144Copyright 2014 Business Architecture Guild
Leveraging Business Architecture to Improve Business Requirements Analysismanagers, agile teams, business process modelers, technical architects, and many otherdownstream stakeholders.Oftentimes, organizations jump into defining the solution before they fully understand theneeds or even the boundaries of the issues. In some cases, tools and/or technology choices aremade based on a presumed understanding of a technical need. Without the traceability back towhat customers want, the execution of changes to products and services is based onguesswork. Organizations cannot afford to rely on intuition to drive sustainable organic growth.The future remains bright for organizations with leadership who commit to driving growth usinga disciplined process for guiding their investments.8 While efforts at solution architecture,technical design, or implementation details are often needed, they are not the core of abusiness requirement. A strong business architecture will ensure that the right requirementsare captured and aligned to drive change.As outlined in the remainder of this whitepaper, business architecture provides a structure forrequirements alignment. The key outcome of business architecture is to provide a frameworkfor the business. The elements of this framework – primarily but not exclusively value streamsand capabilities – can be improved and extended through the requirements of a project. In rarecases, requirements are provided in support of new capabilities. It is optimal in these cases todesign business architecture first, and then provide implementation level details throughrequirements.Business Requirements Analysis Approaches and Best PracticesRequirements management can be broken down into four primary phases: Planning, Elicitation,Analysis, and Solution Design. The expected outputs of this process are specific statementsand/or rules essential to achieve a defined target state, utilizing multiple levels of detail.However, as projects continue to miss delivering anticipated business value within scope, therequirements process will continue to be suspect. Not only is it a common perception that thisprocess is problematic, but opinions are backed by industry statistics as previously noted whereapproximately 70% of software projects fail due to poor requirements9 with an associatedrework spend just north of 45 billion annually. 10Attempts to reverse this trend have brought about the development of several techniques andframeworks, and have also been a dominant driver for organizations adopting ApplicationLifecycle Management (ALM) platforms. Methodologies such as the Rational Unified Process(RUP), maturity in Iterative Development, and Agile have had positive impacts remediating risksassociated with controlling scope, standardizing documentation, and improving business-to-ITcommunications. What still remains to be addressed are several key considerations thatimprove both the formation, capture, and cataloguing of requirements to improve their initialMarch 20145Copyright 2014 Business Architecture Guild
Leveraging Business Architecture to Improve Business Requirements Analysisand ongoing value as a core business asset. The goal can be met by establishing clear businessboundaries for requirements and using these boundaries to improve the resulting requirement,establishing traceability (linking business strategy through solution design), and establishing theability to reuse requirements across common organizational capabilities.Addressing these goals requires a common understanding of the business strategy and needs,regardless of the form of output the business analyst is producing. There must be a frameworkthat provides both the ability and essential artifacts to examine, interpret, and transforminformation (implicit and explicit) that enables sound decision-making. Herein lies the valuebusiness architecture provides to the process of requirements analysis.Possessing these artifacts and perspectives are absolutely critical. Today, business analysts do arespectable job delivering lower-lever, system requirements, but they do not always addressthe true business need. There are two primary reasons for this. First, the business analystdeveloping functional requirements typically has access to technical artifacts to performanalysis – application/information architectures, data-flow diagrams and dictionaries, and userinterfaces. Possessing these blueprints and references creates a common functional context toconnect the dots between ask and system behavior. Second, the majority of business analystsare functionally aligned with IT (65% residing in IT vs. 35% residing within the business unit) 11.As such, responsibilities tend to focus on developing the “what’s” that define the technicalsolution. Although this is a must have capability, this creates an unnecessary gap in the abilityto connect these defined behaviors back through intended business results tied to valueperspectives and capabilities.Business architecture provides the necessary context to narrow this critical gap. As outlinedabove, business architecture provides an essential framework that not only creates the linkagefrom business strategy to business capability through a value perspective, but also the capacityto quickly identify those common, reusable requirements tied to widely used capabilities.Business Architecture as a Framework for Business RequirementsAnalysisBusiness analysts must be able to answer the question “why”. This is not necessarily why theproject was initiated, but why the business requirement exists. Requirements are theinstructions guiding the design of the solution that will create the intended return oninvestment (ROI). Analysts have to represent the output of accurate and thorough analysis, andthey have to be accurate.The recommended approach to effectively address the “why” question is to trace therequirement logic from its basic components – stakeholder, goal, and reason – through itsMarch 20146Copyright 2014 Business Architecture Guild
Leveraging Business Architecture to Improve Business Requirements Analysisorigins and deployment highligh
business architecture and business analysis share some similarities, both disciplines have a distinct purpose, multiple inputs and multiple consumers, and as such need to evolve and be managed as separate disciplines. The blueprints created by a business architect may be used as a framework for business requirements, as we expose further in this whitepaper. In addition, these blueprints assist ...