Capability-based Migration Planning in Business Transformation

In any EA development cycle, migration planning is the point in where architecture turns into actions. As every EA practitioner learns, this is the most critical stage in EA value delivery, because architects have to get out from their modeling caves and communicate with other guys in PMO, Capital Management Office, Change Management Office and other teams in organization, in order to make efficient, rational, affordable and measurable action plans.

In classical migration planning methods, as in TOGAF ADM, migration plans are to be derived from so-called ‘gap analysis’ tables; every to-be architectural asset is cross-checked with its as-is counterpart (actual or virtual) and any gap points to an action. Desired migration plan is formed from collection of such gap-filling actions. Hmm! it works well in most IT-centric use-cases of EA, where architecture building blocks are IT applications and solutions, databases and/or infrastructure assets. But things get more complex when it comes to business transformation.

In case of business transformation, architecture building blocks are business capabilities (BCs), i.e. compound mini-structures comprising 3 different ‘dimensions’: people, process and technology. If one applies classical ‘gap analysis’ method to derive migration actions, result plan will contain different actions associated with these 3 dimensions in separated ‘lanes’ for people, process and technology enhancement. No or little dependencies are around between different dimensions of each business capability which should be moved-forward in transformation roadmap. Following figure shows a schematic transformation landscape in this case:

Such a transformation landscape lends itself to some common problems in business change management scenarios:

• Delayed pre-requisite: some part of a BC is delivered or leveraged by a transformation project, but its associated pre-requisites are not ready to go. So target BC value delivery is failed or at-least delayed.
• Not-synched BC: each part of a target BC has been developed in a different time-frame, with a different variable set of requirements. So they could not integrate into a single consolidated BC to deliver a business value.
• Broken capability: one or two parts of a target BC are ‘missing’ in transformation landscape, because they could not be derived from a layered gap table. For example, think about a missing application service because there were no business unit operating over related target business process, hence no demanding actor for that application service, in time of planning.
• Unbalanced workload: distribution of transformation efforts is unbalanced because there is no guiding principle to set priority of projects in different ‘lanes’ in terms of target BCs.

Shifting to a capability-based paradigm in migration planning could solve most of these problems in business transformation endeavors. If one regards BCs as building blocks of business transformation and derives transformation roadmap from a business capability analysis (see my former post), migration plan could be designed in terms of actions over BCs, so encapsulating people, process and technology sub-projects in a higher level ‘bundles’ of change. Following figure shows a somewhat simplified version of this scenario:

Capability-based migration planning address concerns of different stakeholders of business transformation:

• For senior managers: to shorten ‘investment lag’ between investment in change projects and delivered business value of new or leveraged BCs,
• For change managers: to oversight totality of change efforts from a higher landscape of BC maturity roadmap,
• For program managers: to synchronize multi-dimensional projects in different architecture domains, from people side to technology.