Enterprise assets, including business architecture and BPM operational components cannot simply be split into a strategic/tactical dimension – enterprise assets are usually involved in both. Elements of the enterprise architecture are building blocks that are instantiated and used in solution architectures. They play a strategic role in developing plans to close gaps between existing and desired business value propositions, capabilities and quality commitments. And they play a tactical role when instated for solutions that realize the plans.
Enterprise assets generally follow two parallel life cycles. The work done in these life cycles is usually organized into projects that allocate budget, time, work and resources to meet a set of requirements. Let’s characterize the projects for these two life cycles as Requirements Delivery Projects (RDPs) which address specific requirements for specific business initiatives, and Asset Management Projects (AMPs) that manage and govern rustable assets across the enterprise over time.
The characteristics of these projects are quite different. Requirements Delivery Projects:
- Are often short lived
- Address specific requirements to deliver specific business values/results
- Can have requirements that conflict with those of other projects
- Are on different release cycles with different milestones
- May be critical to short, medium and/or long term business vitality
- Use assets across enterprise business functional areas
- Are often focused on deliverables over commonality/variability analysis required to support development for and with reuse
- Have limited budgets and time horizons focused on the specific project deliverables
- Are not necessarily funded sufficiently for enterprise asset management
- Often have matrix organizations of teams accountable for functional areas as well as specific project deliverables
Asset Management Projects are often quite the opposite:
- Have lifetimes that are tied to the enterprise itself
- Are organized by business functional areas, not specific project deliverables
- Addresses requirements of the enterprise for vitality and sustainability across projects
- Must resolve requirements and component changes across projects over time
- Are on more coordinated, and often much longer release cycles
- Are critical to long term business vitality, business integration, sustainability and agility through reuse, but can have immediate impact on short term goals
- Do address commonality/variability for development for and with reuse, address separation of concerns and refactoring to manage cohesion and coupling
- Need (but often don’t have) independent budgets and supporting organizational structures
- Are funded for asset management and governance
- Often have matrix organizations of teams accountable for different functional areas
It is important to have organizational structure, methods, and practices for harvesting, managing and governing change in enterprise assets across all ongoing projects. Otherwise it may be difficult to manage enterprise assets to avoid redundant development of overlapping functionality, poor adherence to architecture guiding principles, limited reuse, accidental variability, and collisions and incompatibilities when attempting to do enterprise wide business integration.
Enterprise architecture management involves understanding and categorizing the many business functions of the enterprise to establish a context for separation of concerns, minimizing coupling, and supporting asset management and governance. Many organizations realize this, and are familiar with TOGAF ADM. However, some struggle to have an effective EA practice in place. They do have a topology of cross-cutting categorizations of business functions that reflected at least a good tacit understanding of their business. The question is how to use that knowledge to support more effective change and configuration management of enterprise assets, in the context of managing individual project requirements.
One possibility is to take a two-dimensional approach, separating changes for RDPs and AMPs. Each RDP has its own lifecycle project that organizes the teams, processes and work necessary to address its specific set of requirements. These projects result in changes in assets that meet project needs first, enterprise needs second. At the same time, enterprises should create a lifecycle project for each business functional area who’s purpose is to manage the assets of that functional area.
Functional areas are chosen for enterprise asset management because functional cohesion is the strongest cohesion, will likely result in less coupling across projects and assets over time, and facilitate more efficient and effective change management. Some organizations want to create different project areas for use cases, design models, code, test cases, etc. because that is how their teams are organized. But the coupling between use cases, realizing design models, implementing code and validating test cases in a business functional area is likely much greater than the coupling between use cases across functional areas. So these different abstractions of a single functional area are best managed together in the same lifecycle project. Artifact managers within the lifecycle project provide additional separation of concerns relying on project associations to manage the coupling between artifact types.
Each RDP manages change through CCM project area streams. Each stream captures the changes to a set of artifacts contained in (loadable) components over time for some purpose. An RDP will likely have a single production integration stream that represents the artifacts that are delivered from the project. Change sets flow up from developers completing work items to the integration stream, and down from the integration streams into ongoing developer streams to minimize the impact of change. The purpose of the RDP is to deliver the project requirements through the artifacts on the integration stream. Project management and governance controls the flow of change sets between the streams based usually on push models – change sets are pushed or delivered from one stream to another by the team member making the changes.
The AMPs also manage change thorough CCM project area streams. Each stream captures the changes to a set of functionally cohesive enterprise assets, also contained in components over time for the purpose of managing the lifecycle of the assets, improving their vitality over time. AMPs and RDPs can share the same components depending on the affinity of the projects. Often most of the work associated with asset changes are actually done in the RDPs with these changes harvested and hardened for asset lifecycle management in the AMPs by teams responsible for assets in specific business functional areas. Change sets flow up from the RMPs into the AMP streams – often more than one stream, at least QA and enterprise integration streams. Project management and governance controls the flow of change sets between the streams based usually on pull models – change sets are pulled from the RDP streams to the AMP by the the owners of the business functional areas. The AMP change sets are pulled down into the RMP streams for reuse.
The separation of these two dimensions of change provide the project areas, team organizations and stream mechanisms to manage changes made in projects delivering business requirements coordinated with changes made to improve asset vitality and quality. AMPs provide a target destination for harvesting appropriate change sets across possibly conflicting RDPs.