In my previous post I spoke about the cost and complexities of creating a framework for bespoke software. In this post I want to look at how one can evaluate the appropriateness of a framework in the context of enterprise architecture. Such an evaluation needs to take into consideration the operating model of the business as well as the current stage of architecture maturity of the enterprise architecture of the organization.
Detailed information regarding operating models and architecture maturity can be found in [1] (with some information available at [2]). Here I will just provide sufficient information on these to support this discussion.

Operating Model

An operating model defines the necessary level of business process standardization and data integration required to run the business effectively.  Business processes are standardized when they are the same across organizational units. The level of data integration required is typically driven by the proportion of customers shared across organizational units. Based on the required levels of business process standardization and data integration, different general types of operating models can be defined:

• Diversification – Different organizational units have different business processes and different customers.
• Coordination – Different organizational units share a large number of customers.
• Replication – Different organizational units have a set of shared business processes.
• Unification – A set of business processes and customers are shared across organizational units.

Organizational units in this context can refer to any unit within an organization, i.e. business unit, department, branch etc. Different operating models can be defined for different levels of organizational units.

Architecture Maturity

Even though the business may be characterized by a specific operating model, this operating model may not be well expressed in the current enterprise architecture of the organization.  The different stages of architectural maturity give an indication of how well the operating model is realized within the software systems of the organization. The stages of architectural maturity are defined as follows:

1. Business Silos – The key business driver at this stage is to encourage innovation with organizational units largely operating independently. Key characteristics of this stage is a proliferation of technologies and solutions
2. Standardized Technology – Proliferation of different technology platforms during the Business Silos stage increases operating costs. The Technology Standardization stage aims to reduce operating cost by reducing the number of technology platforms.
3. Optimized Core – Business processes and data are standardized throughout the organization in accordance with the operating model of the organization.
4. Business Modularity – Reusable system modules are leveraged to enable business agility.

Evaluation

Martin Fowler in his Analysis Patterns book states [3]:

To accomplish component reuse for information systems, a common framework must be established. An effective framework must not be too complex or too bulky. It should be widely applicable across a large domain and be based on an effective conceptual model of that domain. Developing such frameworks is difficult, both technically and politically.

In order for a framework to be widely applicable, it needs to be closely aligned with the operating model of the organization. Creating a framework for optimizing business processes in an organization with a Coordination operating model is probably not a smart move.  In a similar vein creating a framework in an organization with a Diversification model may not provide adequate return on investment (ROI).
The architectural maturity stage of the organization has to be able to support building of a framework:

• Building a framework during the Business Silos stage will politically be a difficult sell due to a clash of priorities. In order to be successful at building a framework, the stability and integrity of the framework has to be preserved at all cost. This may mean that the implementation of new features needs to be delayed to maintain framework stability and integrity [4]. This approach is clearly at odds with the typical time-to-market pressures of the Business Silos stage.
• It may be tempting to create a framework at the Standardized Technology stage, but lack of standardized data access and business processes will result in limited opportunities for reuse. Proponents may argue that a framework may be the means through which an organization progresses from the Standardized Technology stage to the Optimized Core stage. Still, in order to be successful, standardization needs to precede framework creation.

Summary

In closing, here are my general rules of thumb regarding framework development:

• Consider creating a framework only for organizations which has a Coordination, Replication or Unification operating model.
• For a Coordination operating model focus framework design at optimizing data access.
• For a Replication operating model focus framework design at optimizing business processes.
• For a Unification operating model aim framework design at optimizing data access and business processes.
• Create a framework only when the organization has reached the Optimized Core or Business Modularity architectural maturity stage.

If you consider deviating from these guidelines, it will be in your best interest to have a watertight; well documented business case, signed-off by the relevant stakeholders.

Bibliography

[1]     J. W. Ross, P. Weill and D. C. Robertson, Enterprise Architecture as Strategy: Creating a Foundation for Business Execution, Harvard Business School Press, 2006. http://www.amazon.com/Enterprise-Architecture-Strategy-Foundation-Execution/dp/1591398398
[2]     “Center for Information Systems Research,” MIT Sloan Management, April 2013. [Online]. Available: http://cisr.mit.edu/research/research-overview/classic-topics/enterprise-architecture/.
[3]     M. Fowler, Analysis Patterns: Reusable Object Models, Addison-Wesley, 1997. http://www.amazon.com/Analysis-Patterns-Reusable-Object-Models/dp/0201895420
[4]     J. Tulach, Practical API Design: Confessions of a Java Framework Architect, Apress, 2008. http://www.amazon.com/Practical-API-Design-Confessions-Framework/dp/1430243171