Identifying the key incentives & drivers for change is one of the most important and challenging aspects of developing an organizational and technical strategy.
After developing a business case to determine drivers and potential benefits, the organization is in a position to focus on developing a change strategy.
The need for change must be clearly defined and accepted by key stakeholders, while the benefits to be derived by the enabling changes articulated, documented, and accepted.
Benefits may yield both tangible and non-tangible results, while a collaborative approach to defining these prepares and plans the implementation programs to follow.
The first step is to ensure communication and engagement between sponsors, & stakeholders in producing the key value propositions, and prioritizing these. This approach applies just as much to pure organizational objectives as to technical and engineering goals.
A thorough understanding, or research into present and future conditions ( states ) will help in shaping target drivers and establishing an initial road map for implementation. The social, process, and organizational components which lead to value IT shaping a portfolio plan are discussed elsewhere,in this discussion focus is on certain methods for developing a change program.
Other than poor execution one of the biggest causes of program failure is lack of real or perceived value and acceptance. Therefore establishing a strong buy-in up front, identifying value and reasons for concern should be a priority. Often, the level of dissatisfaction among staff, loss of revenue, and competitive threats provide sufficient grounds for action, but relying on experience which may be limited, or fragmented, does not produce repeatable outcomes.
The use of enterprise architecture in defining the details of an operating model for an organization will guide change in formal, structured, and visible manner.
While engaging personalities and complementary personal leadership attributes make a difference in developing and managing change processes, and they are needed, these alone are no substitute for clarity through method in definition and acceptance of common goals especially where organizational governance is concerned.
Progress against a well defined baseline needs to be measured, relative to which controlled changes may be made, with reduced impact to all concerned stakeholders.
Additionally, structure reduces the number of decisions which need to be made in coming to a mutually beneficial conclusion.
The term “architecture” is somewhat loaded as focused on technical aspects, but this is not the intended scope of the change initiative. Technical and engineering aspects will inform and detail a company operating model, derived as result of the enterprise or point business drivers and organizational objectives.
Architectures divorced from operational reality, established in an ivory tower are not useful in developing transformation objectives.While useful as a guideline to execution, they often take a tactical path to a solution without considering the cause of the problem itself, and the nature of requirements.
Indeed in certain cases a ready made solution is offered before taking into account all the preceding factors, such as capability, existing state, and organizational inertia. As an example certain fads drive initiatives, agile, dev-ops, are useful solutions applied without adequate problem definition. Time is often an issue and a quick-fix imperative overrides analysis, costing, and planning.
With regard to timing imperatives – a short period of reflection and structured alignment of objectives with people, and capabilities will pay off in an accelerated transformation to follow. Modelling, costing and scenario planning on resulting benefits yields an action plan. Governance will address execution and accountability.
As stated in multiple references enterprise architecture is the organizational structure for integrating and standardizing a company’s operating model. It sets the tone for understanding external and internal business requirements and provides a method for visibility and control. It is not restricted to IT but is informed by and contributes to all aspects of operations, in terms of revenue and cost.
It helps to formulate an operating model in the context of a particular domain. Logistics requirements are different to those of running a municipality although they may share technology and common skill sets.
Recent work with several companies, and exposure to individual methods of working, including those developed internally, yield at least four/five areas in capability management, demand and supply, governance, namely : (i)business process, (ii)data, information & security, (iii)application integration, (iv) and technology.
If working with an extended partner network, then we need to include the partner integration methods and processes ( we get into various aspects of trust in contract formulation, traceability, and alignment ).
When informed by an accepted value proposition (Business case ) and well defined drivers these techniques represent powerful tools in resource allocation (who does what ) organizational structure, and capability development, leading into the details of building a foundation for execution, with or without external partners.
Developing an external supplier engagement, and aligning internally between organizational silos, in absence of drivers, business benefits, and aligned architecture, may lead to all sorts of communication, funding, and technical issues, compounded by time imperatives, and inertia.
Addressing these aspects up front engages people, identifies costs, provides valuable shared information and drives the selection of an optimal solution.
Change through developing the program for execution becomes a natural outcome of shared objectives, and value resulting from that change well understood.
 Enterprise Architecture as strategy – Harvard business school press
 Benefits Management – Delivering value from IS & IT investments – Wiley
 TOGAF – An open group standard
 Telekinetics – A value & domain based approach to service provider transformation