Most organizations routinely overlook Business Architecture. Those organizations that do consider it seem to think of Business Architecture as something distinct and separate from Enterprise Architecture. It is not.
Enterprise Architecture is not about technology; it is about the enterprise—the whole enterprise. It is about the people: internal and external. It is about the business processes: strategic, core and support. And, it is about the technology that supports the people and enables the business.
Business Architecture: The “Operationalization” of the Business Strategy
An Enterprise Architecture comprises two major components, the Business Architecture and the Technical Architecture, into which all other architectural components fit. Business Architecture defines the structure of a business in terms of its components, and how they operate with a special focus on the integration and interrelation of people, processes, and information. It considers the ever-changing market, customers (whose businesses constantly change in response to their respective markets), and finances, to make decisions regarding products and services, partners and suppliers, core business processes, organization, and technology.
The driving force behind the Business Architecture is the set of strategic, core and support processes that transcend organizational boundaries. An effective Business Architecture enables a planned approach to process integration across organizations. As such, instead of applying business-enabling technology to integrate silos and make them more efficient, an end-to-end value chain is applied to break down those silos. While we may all belong to a particular organization within the enterprise, such as Finance, IT, Sales, or Customer Service, our business processes are not constrained by the organizational structure.
Alignment: Is it even possible?
The question becomes “How do we close the gap between the business and IT?” If the Enterprise Architecture comprises the Business Architecture and the Technical Architecture, and all other architectural components fit into those in some capacity, which components of the Business Architecture influence corresponding components of the Technical Architecture? How does the Business Architecture leverage components of the Technical Architecture? And what is the mechanism to facilitate the necessary communication between these components?
The most direct influence by the Business Architecture on the Technical Architecture comes from the Functional Architecture; the set of customer-facing core business functions, or those that directly influence revenue. It is against the Functional Architecture that the Application Architecture, a component of the Technical Architecture, is rationalized.
Having established the Functional Architecture, business priorities determine which, if any, core business functions require further elaboration. For those that do, process models are developed and a Process Architecture begins to emerge within the Business Architecture. The Process Architecture not only demonstrates end-to-end business processes, it also identifies the informational needs and outcomes of the processes and the cross-functional collaboration required to execute each process effectively; and operational silos begin to crumble.
The Process Architecture tells the Application Architecture what data to pass between applications and when, and the Integration Architecture, another component of the Technical Architecture, allows the many applications to “talk” to each other, by virtue of their respective APIs and assorted middleware, as directed by the business processes.
The Business Process Management Suite (BPMS) is the mechanism for communicating between the Business and Technical Architectures. While BPMSs come in many sizes, shapes, configurations and capabilities, they are designed to capture business processes and improve and/or automate them as much as possible to enhance operational efficiency. This brings into play the Services Architecture component of the Technical Architecture. By using the Process Architecture to identify services common to multiple business processes, a services-oriented approach results in the Services Architecture. A well-implemented BPMS can then leverage those services, monitor the effectiveness and efficiencies of the business processes, and give rise to further process improvement.
Governance: Include a cycle of feedback and adjustments
Well-defined business processes include metrics and a means to capture and report on them; if you’re not going to measure a process, there’s no need to document it. Monitor metrics at regular intervals. (Metrics’ granularity can determine the level of regularity.)
At the lowest level, conduct weekly reviews to track individual initiatives. Every month, summarize weekly reviews for a program of related initiatives. Conduct quarterly reviews of the entire portfolio of investments made in the core business functions. Use these portfolio reviews as input to semi-annual business planning conducted by each business unit, and consider the net result across the enterprise as annual strategic planning takes place. This produces a continuous cycle of adjustments that keeps the enterprise agile and responsive to the market.
And the final piece of the puzzle: Include formal Organizational Change Management. Doing so will ensure that adjustments made as a result of process improvement, BMP, or service development initiatives and their respective, collective review cycles are absorbed effectively, and do not exceed the organization’s capacity to change.
