George and I are often asked “How is EA different between smaller and larger organizations?”
There are a number of differences (amount of available resources, degree of complexity, flatness of the organization structure, number of elements in the application portfolio, etc.) that affect the approach, effectiveness, readiness and deliverables of EA. But one that I think is one of the more complex to deal with and has the biggest impact on the effectiveness of, is the level of federation vs. centralization of EA.
In a smaller organization, there is much more of a tendency to standardize as much as possible due to the lack of resources for specialized technologies and skills and the propensity to outsource as much as possible, especially now with the progress of the cloud. In larger organizations, there is usually a lot more inertia behind standardizing the infrastructure beyond the desktop, outsourced or not, while a lot of pressure from business users to have uniqueness at the desktop and within the application and data portfolios. While this pressure exists from individual users or departments, there seems to be a lot more understanding within the business leadership that complexity and costs are getting out of control without more standardization of systems and data. So the question becomes “What do we standardize and what do we federate?”
Three keys to being successful with federation decisions:
- Understand your business’ operating model. As discussed in a previous entry, the operating model concept from “Enterprise Architecture as Strategy” is a guide to the level of business process standardization (application standardization) and business process integration (data standardization) that the business requires.
- Develop a capability map or taxonomy for your systems to identify the overlaps that exist within your application portfolio. These capabilities tend to be a mix of functional (business) and technology capabilities that are delivered by automated solutions. Using a simple matrix to relate your applications to the capabilities delivered by that application tends to be very revealing of the potential candidates for reducing redundancy. However, capabilities are defined at a higher level than individual systems user requirements, to there is still going to be some compromising that is necessary when eliminating/replacing duplicate applications.
- Don’t go overboard. Not everything that could be standardized needs to be standardized. Identify the areas that will have the biggest impact, whether that be cost savings or increased functionality or good will, and prioritize standardization efforts accordingly.
As you develop a better idea of what areas to standardize, you can begin institutionalizing your foundational architecture within the infrastructure, operations and development groups. This will result in professionals in these areas spending a majority of their time on areas that are unique, and quite likely contribute to the competitive advantage of your business.