Break Horizontal Silos Between Architecture Layers
Look at a medium to large-size organization structure; you will find distinct layers consisting of people and the functions they fulfill, such as individual contributors, their managers, directors, vice presidents, and executives. Similarly, when we examine a technology division of an enterprise, we discover horizontal layers, each responsible for different pieces of architecture work:
- Software engineering teams, their development leads, and application architects define and implement structures within the systems or at the code level.
- Solution architects decide boundaries and integrations between systems and subsystems.
- Data architects contribute designs and workflows of data, from source through transformation and into the target systems.
- Technology architects govern available instrumentation and toolset to build, deploy, monitor, and maintain IT solutions and systems.
- Enterprise architects cooperate with the above-mentioned technical architects and business stakeholders to align the two sides of the organization.
After examining multiple technology organizations, we discovered that there are horizontal silos between the layers of architecture. Specifically, here are examples of challenges that we witnessed and observed, both personally and after interviewing others:
- Software engineering teams and application architects receive minimal guidance from solution architects, resulting in over-engineering or complicating systems and integrations.
- Solution and data architects have no access to application architecture to review and provide feedback, resulting in suboptimal systems and a lack of feedback loop.
- Solution, data, and technology architects work in isolation, unable to exchange design ideas.
- There is a disconnect between enterprise architecture and other architecture domains to align on strategic initiatives and deliver optimal solutions.
We have also seen positive traits in some cases, which is good news. However, in most of the enterprises, we saw horizontal silos between architecture layers. Below, we want to suggest an approach that we have tried, and it worked.
Integrating Architecture Initiatives Vertically
First, it is imperative to understand how various architecture initiatives relate to each other and how everything fits together. On top, we have enterprise architecture, and at the bottom - software engineering teams. Below is our attempt to visualize this structure, where each cell has its distinct purpose and function. We intentionally kept the business architecture out of the scope for now since we wanted to focus on the technology organization's structure. However, if we wanted to add the business architecture, it would be at the same horizontal layer as solution architecture.
Having so many distinct architecture domains, it is natural that silos can develop organically. While ideally, these various initiatives must cooperate, in practice, each has proprietary tools and processes that are not compatible out of the box. So how do we integrate all these architectural functions?
Embrace Diversity of Domains
Let's agree that having differences between domains is a strength rather than a weakness. By no means would we want all architects to do their jobs similarly; it would not go far. Each function needs to fulfill the duties in the optimal and well-known fashion recognized in the respective field of study. Thus, Solution Architects need to employ patterns and techniques different from those acceptable for Data Architecture.
Instead of the unification of disciplines, we prefer advocating for cooperation between them.
Integrate Processes
Silos between the disciplines emerge naturally as each represents a social vacuum. Proper culture directed towards teamwork and shared goal can be the needed motivator to integrate processes.
The overall process must cross all domains and connect the efforts seamlessly, using two-way knowledge sharing and feedback loops. In the presented figure, such cooperations should happen between horizontal layers and cells within the layer. Only such a holistic approach will let us realize the value promised by IT-to-business alignment. Indeed, what benefits do we get from having an Enterprise Architecture initiative if the engineering teams implementing solutions cannot leverage that knowledge to align strategically and deliver based on business objectives?
Below is the updated table with disciplines, where each architectural function interacts with and supports others.
Support with Tools
Finally, we arrive at tools that could support you when breaking horizontal silos within the technology organization.
Archipeg is a cloud-based digital enterprise architecture software built with the holistic and end-to-end integrated view out of the box. Organizations that want to align all technical efforts use Archipeg as the centralized architecture knowledge repository.
Within Archipeg's subscription account, you can invite all architects and technical leaders who create or consume digital architecture knowledge. Each member can leverage the access to the holistic architecture, analyze it, review and refine it. Optionally, each group could have their own Archipeg project under the organizational subscription account, sharing their assets and providing feedback while keeping their workstreams isolated if they don't naturally connect. With a tool like Archipeg, end-to-end architecture reviews and learning initiatives become possible.
Under a single Archipeg project, assuming you follow the Archipeg EA Framework v1.0 metamodel, you can capture assets of all architecture domains, ready to share with others:
- Business - company-related: describe the company's internal structure and processes. e.g., in this area fall things such as company's branches and business processes.
- Business - customer-related: describe the landscape from the customer's standpoint. e.g., a customer might sign a contract or employ end-users who use the company's products, services, or applications.
- Business - people-related: depict the environment details from employees' standpoint, such as roles that they serve or the groups where they participate.
- Business - cross-cutting: apply cross-cutting concepts to the landscape such as location, which can describe where the other objects are located, either physically or virtually.
- Data: describe data objects and associations between them.
- Applications: describe solution and application architecture elements, including applications and their deployable components.
- Technology: define supporting aspects to the information systems and business architectures. e.g., here, you can specify equipment or third-party software in use by the employees.
Traditionally, enterprise architecture and solution architecture have been silos inaccessible to the rest of the organization. With Archipeg, we are changing those rules since it is the only approach that truly maximizes the value delivered by digital architecture initiatives. Start your free 30-day trial with transparent prices, and let us know what you think.
See Also