Often organizations embark on projects that require new business and IT capabilities, but neglect to invest in the necessary business architecture before and throughout the project. Business architecture in this context is the development of a shared understanding of the structure, motivation and function of the business today, how the business must change to meet project objectives, and how the business is likely to evolve after the project completes. The absence of this shared understanding can compromise an entire chain of deliverables from requirements and IT architectures to implemented processes and systems, resulting in project failure.
Organization embarking on transformational projects must typically define two dimensions of business architecture: targeted organizational change, and project execution. Targeted organizational change encompasses the business capabilities and business results the organization wants out of the project, while project execution is everything it takes to manifest those capabilities and results. For example, an organization developing its first mobile consumer experience may require new software applications with underlying services and data, along with the capabilities to monitor, support and evolve that experience. Project execution to deliver this targeted organizational change may require new capabilities in user experience design, software development, analytics, and infrastructure.
Many organizations use agile methods to deliver the most important features of a project first, learn from what they have delivered, and quickly apply what they have learned to new or revised features. Agile methods are mainstream today, and work well for many organizations, but are often poorly integrated with enterprise architecture in general, and specifically with business architecture.
The Scaled Agile Framework (SAFe) offers a path forward. It defines business epics as “large-cross-cutting customer-facing initiatives”, and recommends a kanban system to manage them. Under this system, each sufficiently prioritized business epic participates in an Analysis Phase, in which a business analyst collaborates with architects and many other stakeholders. In this phase, or in anticipation of this phase, business architecture practitioners should build, extend or refine the deliverables necessary to develop a shared understanding of how the organization must change to realize the business epic.
What business architecture deliverables should be produced in the analysis phase? Ideally, each organization should develop their own business architecture methodology based on key standards such as the TOGAF Architecture Development Method (ADM), and the Business Architecture Body of Knowledge (BizBok). For organizations that need a quick start, though, here is a minimal example that outlines a basic set of architecture and design responsibilities, beginning at the top with business architecture. The recommended views are based on standard ArchiMate viewpoints, and responsibility for the starred deliverables should be shared with the data architecture and data analysis practices.
Business architecture artifacts, like any other architecture work, must be continuously used, revised, and elaborated with designs in order to keep business epic implementations on track. As an enterprise architect who also serves as a solution architect, or system architect in SAFe parlance, I work with product owners to write and prioritize spikes to update architecture artifacts and elaborate them with designs. We work on these special-purpose stories even as development teams are delivering software, and business analysts are designing processes. These clarifying spikes keep the project on track.
How do you apply business architecture to agile development efforts? What challenges have you encountered? How does business architecture help projects in your organization realize their objectives? Please post your comments.
Best Regards,
Iver
[email protected]
