In the realm of Information Technology, a commonly-employed software development methodology is the Systems Development Life Cycle, usually abbreviated SDLC, which describes a systematic, if generalized approach to developing and deploying new software. While details can vary, the steps typically include analysis, design, implementation, testing, and maintenance. However, since IT can be an integral part of the overall business architecture, it follows that there must be an analogous, higher-level process that spans the development and deployment of a business architecture, to wit: the Business Architecture Life Cycle (BALC).
What is the scope of the BALC? Generally speaking, as its name implies, not only does the BALC include the business architecture itself, but also all aspects of its life cycle, specifically: its creation, planning, execution, maintenance, and retirement, plus its overall management and monitoring. Given that a business architecture is the set of independent processes of the extended enterprise and the relationships between them, it must also include the data and processes of the value streams at a high level as well as their decomposition into detailed business rules and business data, and ultimately into the services which implement them. By definition, anything that can happen to that business architecture must be included in its life cycle.
Looking more closely at the individual phases of the BALC, it begins with senior management at the enterprise level. In the beginning, the strategy is captured as a simple graphical model identifying the problem to be solved, the desired outcomes, and the inputs which necessarily drive them. Thus, the business architecture is born.
Next, the model is expanded via decomposition to show all of the independent processes which make up the strategy, plus the relationships between them, thereby defining the scope, requirements, and the management structure of the solution. Additionally, it provides a high-level blueprint for system testing, resource allocation, and monitoring as well as defining the structure of its documentation and providing placeholders for the detailed documentation. Typically, this enterprise-level model includes not only the value stream of the ultimate “to be” solution, but also that of the “as is”, plus the process for migrating from one scenario to the other. Thus, the business architecture grows and matures.
At the business level, the enterprise model is decomposed further to describe the business rules and business data, thereby defining the functional specifications and design of the detailed business architecture. Here, the SDLC begins to overlap the BALC, where the model is ultimately brought to a level of specificity that shows how it directly connects to the implementing services, thereby forming a codeable spec or, if an automation engine is available, a directly-executable model. The decomposed model also provides a roadmap for the maintenance of the business architecture as well as hosting its detailed documentation. Thus, the business architecture comes to life, and its value streams proceed to fulfill their strategic purpose until the day it serves as the “as is” model for its own partial or complete replacement.
It is important to note that the phases of the BALC need not follow one another in a lock step fashion; an agile approach can also be taken. For example, once the enterprise-level model is completed and shows all of the independent processes of the value stream, any one of the processes can be separately addressed, or any portion of their business rules or implementing services, for that matter. Nor does the approach need to be strictly top-down; pre-existing business rules and processes can be integrated into a new value stream, as happens in the case of a merger of two business architectures. Un-integrated, stand-alone subsystems of business rules or manual processes can also be used as a starting point to define a new, heretofore undocumented value stream, ultimately growing into its own business architecture or being assimilated by another. Unlike the SDLC, with an agile BALC one can start anywhere and still end up with a complete, meaningful business architecture.
To summarize, where the SDLC followed the path of analysis, design, implementation, testing, and maintenance of software, the BALC spans the strategy capture, requirements definition, functional specifications, design, implementation, testing, maintenance, and retirement of value streams and their component processes, with their management and documentation tightly integrated into all phases. Thus, the BALC is a multidimensional construct, ranging from the beginning to the end of the value stream, from their high-level enterprise viewpoint down through the business rules to their implementing services, from their “as is” birth to their “to be” retirement, all within a single, holistic model.
The BALC is much more comprehensive than the SDLC, much less fractured than Zachman, and an indispensable tool for managing value streams across the extended enterprise.
