How are companies organizing their architecture practice? Primarily how the Enterprise Architecture, Solution Architecture and Application Architecture organizations are defined and how they are integrated into the Product & Engineering organizations.
Sort by:
Having a centralized enterprise architecture group helps ensure tools, standards, and practices are consistent across the organization. Having said that, it is also important to have solution and application architecture groups reside within the business units to narrow down specific technology support needs. This blended approach establishes governance as well as democratizes certain aspects of the solutions and applications. We have seen good success overall.
Product, Engineering, and Architecture have to be in tight collaboration to enable successful launch of any application. This can become challenging at times due to multiple stakeholder involvement but if executed properly with dedicated application/product architect and engineering leads working with product leads, can yield great results.
Thanks <mention id="63c852bb4126640001660dbd" displayname="Abhi Shimpi"></mention> for the response. Within a specific BU do companies have embedded architects under each leader or tower or fold all architects under one leader but dotted line to product engineering leaders? In my current company we have enterprise and solution architect under one leader and application architecture is split between reporting under product/engineering leads who manage those applications vs some are under the architecture leader. I understand the aspects of working and collaborating together. I don’t see a cohesive architecture strategy between Enterprise, Solution and App architecture and often creating duplicate artifacts in different tools and missing connectivity.
Duplication can become a real problem with having BU specific architecture group and not having some sort of enterprise architecture council. The council has representation from all BU’s. We have established council that drives enterprise directions and also provides guiding principles to BU architects. For all new technology needs the council is consulted and approves to avoid duplication of capabilities. <br><br>I have seen reporting structures both ways, having centralized architecture group with dotted line architects assigned to specific BU as well as having BU specific technology heads that own their architects. There is no right or wrong way, but as mentoring having a council established to govern enterprise guidance is key. Also, domain knowledge is very important so BU architects need to have that background and knowledge to serve to their capacity. <br><br>Hope that helps!!
A case for decentralization.
Over the last decade there was a case being made on centralization, single pane of glass, and single vendor homogenization. With advances like AI there is rapid development and disruption of vendors and products in every layer of an enterprise stack. If this is the case, we need individual innovation across these 3 areas: enterprise data/IT, solution landscape, and individual product or application landscape. Setting up the organization across 2 or 3 architectural committees helps to move decisions faster.
We have Teams channels and Wiki pages to document and make async decisions. Only use meetings when there are decisions that cannot be resolved. Previous ways of meeting bi-weekly or monthly for arch decisions are gone. Decentralize, move fast, and shamelessly leverage best practices published in blogs.