Organization Silos Impeding your Enterprise Architecture?
There are countless sources extolling the benefits of a strong enterprise architecture strategy. The experts all agree on an effective enterprise architecture and even more so the larger the organization’s consumption of IT services. But recently, I’ve been reminded that the IT organizational structure, especially the structure aligned to providing new projects and new technical solutions has a dramatic impact on the ability for an organization to realize the benefits of established enterprise architecture.
In short, the more the IT new project and solution delivery organization is directly aligned with the individual business unit or group it supports, the more likely a spaghetti architecture will be the result. To help outline this point, below is a quick graphic of a sample organization chart that shows the two extremes:
Extreme A = Business group/unit functionally aligned:
Extreme B = Common function/service aligned:
The “extreme A” example is functioning with each vertical group acting as silo. Each silo is held accountable for delivering solutions to their business unit. In turn, each business unit will drive their IT silo to meet their needs exclusively. There is no inherent need to collaborate with their peers supporting other business units even if there are “enterprise architecture goals”. In my observation, collaboration might actually be viewed as a distraction to getting work done. There is essentially no organizational driver to force standard solutions and re-use of technology assets.
Sure, an architect in one group might have a strong personal relationship with an architect in another group, but unless they are trying to share ideas that happen to be at relatively the same level of “maturity” for each silo’s needs, they will unlikely be able to produce a common, re-useable technology used across both silos. Architect A attempts to work out a common solution with Architect B but suddenly Architect B’s project gets accelerated. Suddenly Architect B has to quick assemble a slimmed down solution that can’t be dependent on Architect A’s requirements or time-line. And sure, everyone might meet and agree to “retrofit” Architect B’s project with a more standardized solution with Architect A’s project in a later phase/iteration, but it would take an amazing level of cross-silo organizational governance to make sure that happens. If that standardization would in any way delay Architect A’s silo from delivering from the business, the standardization most likely gets pushed far and far out until no one remembers or even exists that remembers why the architecture alignment was needed in the first place.
Other potentially non-technology specific negative byproducts can evolve from this structure:
-
Strong versus weak silos
One silo maybe more effective at deploying more current technology by the very nature of the business unit’s needs. As an example, consider a customer product or engineer unit compared to say, finance or one that uses in-house developed technology versus another with outsourced/SaaS technology. This creates a problem of talented architects and developers/others actively seek out roles within the perceived “strong silo” creating an even stronger silo compared to the other silos.
-
Overall increased IT cost of ownership
As each silo is standing up technology to meet the business unit’s needs, they are all solving basically a significant number of the same problems with different solutions. Those solutions come with reoccurring maintenance, product end of life and all the traditional support and vendor management overheard. (I’ve written extensively about vendor management in past articles.) Then, to drive up costs even further, as some business need to see a “single view of the customer” or some other cross silo business challenge pops up, the cost to map all the data across the disparate systems is exceedingly high. In addition, not only does the mapping need to occur, but the technical (and probably some business) workflow needs to be altered to continue to keep all the data in sync. Someone suggests we need “Master Data Management” and now you have the cost and complexity of implementing a system to manage the data across all your systems.
The “extreme B” example brings the solution needs from each separate business unit/group into a common functionally aligned project delivery discipline. The goal is to leverage best practices/success stories from working with one business unit/group across to the other business units/groups via the common management structure by discipline. More specifically, the goals and objectives of each IT service discipline or function can be aligned to efficiencies and re-use within the specific discipline. Project Managers ensure they have common mechanisms to track and report on the project process. Business Analysts make sure they have a common framework for capturing requirements. Architects, develop unique frameworks for common requirements across all projects. Developers follow a consistent coding standard and reuse objects for data access, error reporting, and instrumentation, etc. The same goes for the other disciplines. Each discipline can focus on efficiencies aligned within their area of responsibility. And since each discipline has a somewhat singular work input and output for all business units, there is complete enterprise visibility to what is needed per each discipline. Thus, ultimately, the architecture team is looking across the entire enterprise at all the requirements and multi-year plans and can be charged with common frameworks for essential IT needs:
- Authentication
- Authorization
- Entitlement Management
- Business Rules/Workflow Management
- Business Event Management
- Reporting
- Data Structure, Storage, Management, Retention, Archiving
- Auditing and Compliance
- Capacity Planning
- Disaster Recovery
… and probably a bunch more that don’t immediately come to mind!
In conclusion, a strong enterprise architecture strategy gets a significant boost from a discipline aligned organizational structure rather than a business unit/group aligned structure.
Anyone have any thoughts to support and/or contradict my thoughts here?
