A CIO’s Guide to IT Organizational Transformation Part 3: Architecture and the Role of Architects

Greg Athas, John Jacobs, and Scott Decker

A CIO’s Guide to IT Organizational Transformation Part 3: Architecture and the Role of Architects

Architecture and architects are often viewed as relics of waterfall processes, siloed off, and producing designs that rarely reflect final implementation. In this third installment of our series on IT organizational transformation, we describe how the essential architectural activities of decomposition, commodification, and lightweight governance enable a successful agile ops transformation. We then further detail how architects can adopt a team-centric, hands-on approach to support continuous transformation.

IT Organizational Transformation: Decomposition

Well-designed software is broken down into small independent components or products with clear separation of responsibilities. This enables independent development and delivery of capabilities with interactions and dependencies expressed through APIs.

Domain-driven design is an established way of identifying the key technical components of the system and an effective structure for aligning teams. However, as we’ve seen in our previous post on team topologies, constraints such as regulatory compliance, team geographic distribution, and multiple consumer channels can expose communication, cognitive, and technical boundaries that impede delivery flow.

An effective system architecture must account for the reality of these fracture planes. For this reason, architects must be engaged in agile transformation from project inception to supporting each iterative release.

Architects should work in tandem with business and product teams to design a socio-technical architecture (team structure and architecture) that balances the tradeoffs between natural domain boundaries and additional fracture planes present in the transformation.

Continuous assessment of the socio-technical architecture needs to be made during transformation to validate team independence, uncover unexpected dependencies, and account for changing communication channels as the organization transforms. Some effective heuristics for evaluation include: meeting frequency, product testability, and API directionality.

Meetings Frequency

As new products/teams are created, it is natural for there to be multiple meetings to design solutions with teams of all types (i.e., collaboration mode of communication). However, as product boundaries are clarified, the number and types of interactions with other teams should reduce, with published APIs and consumer-driven-contract tests being the primary methods for inter-team decision making (i.e., X-as-a-service mode of communication). If teams continue to wait on other teams before releasing, the socio-technical architecture needs to be revisited.

Product Testability

A team’s feature or product should be able to be tested in isolation with as few dependencies as possible. This is particularly true for platform teams, who should be able to test their systems in complete isolation. If a product requires many other systems to be testable, revisiting the product decomposition should be done to find cleaner boundaries or different organizational structures.

API Directionality

Natural hierarchies or layers evolve in an effective socio-technical architecture. Platforms and complex systems emerge as “leaf nodes,” while stream-aligned teams tend to stack into customer journey-focused features and core business domains.

In this hierarchy, teams building features require the most independence and need for speedy delivery. Decoupling is achieved by allowing direct API dependence only downward with upward communication restricted to events. This allows the different layers to evolve at different velocities. Circular API calling between layers is a sign that further architectural decomposition is required.

IT Organizational Transformation: Commodification

It is important to identify platforms that can be outsourced or purchased. A successful company focuses on and invests in what they uniquely do best. Creating and managing home grown versions of commodity technologies is costly and does not benefit from the economy of scale and focused expertise that commercial or open-source platform offerings can deliver. It’s important for architects to identify technology capabilities where in-house expertise will provide strategic business differentiation, and which do not.

A good architecture needs to balance the benefits of commodity with the risk of vendor or technology lock-in. Clearly identifying interfaces and interactions with third-party platforms is essential. This can be accomplished by choosing solutions that provide industry standard or open-source APIs (e.g., the Kubernetes API) on top of their proprietary systems or leveraging tools with abstraction interfaces like Hashicorp Terraform. If these are not an option, organizations can build their own bridging layers, though the effort for this must be weighed against the cost and value.

IT Organizational Transformation: Lightweight Governance

While team independence is foundational to delivery flow, as products and organizations scale some governance becomes critical. The nimbleness and independence of teams can quickly be lost to time spent creating adapters to other team systems, building expertise in compliance, and reinventing duplicate platform components.

To accomplish this, architecture should move from a documentation-centric and hands-off model to an engaged and service-oriented approach. Architecture should provide working code, templates, and tools that make it easy for teams to implement code that complies with governance rules and standards. Governance and compliance should be expressed in code and enforced primarily at the domain layer through automated testing in continuous integration and delivery pipelines that validate API and non-functional requirements.

Teams should be encouraged to experiment with technology choices and architectural variants in their bounded product domain as aligned with global standards. This enables team level innovation while limiting negative impacts through the natural bulkheads of the decoupled system architecture.

IT Organizational Transformation: The Role of Architects

As demonstrated above, effective architecture should be a continuous process leveraging the same incremental feedback loops as any agile deliverable. Architects should abide by the same agile tenants as any other member of the development team.

Most architects should be members of a stream-aligned, platform or complex-system team and represent the team in an architecture community of practice (CoP). The team architect builds domain expertise, supports onboarding and mentoring teammates, evangelizes the system architecture, and educates on governance standards. They also bring the team’s concerns and emergent ideas to the CoP. The CoP is led by a small group of architects who act as an enabling team to facilitate cross cutting concerns and unblock inter-team dependencies.

Architectural artifacts such as diagrams and architectural decision records (ADRs) should be managed using the same agile processes as development and treated as living code—managed in source-control-like code, and open for anyone to view, comment, and contribute. Definition of done for a sprint includes keeping architecture artifacts up to date and labeled with released software.

Putting It All Together

In this article, we’ve shared how architecture is an essential component of organizational transformation delivering a socio-technical structure concerned with both teams and system architecture. Like all elements of agile development, this structure is constantly evolving and requires continuous monitoring and feedback.

Good architecture is everyone’s responsibility, and architects need to be hands-on and part of development teams to help balance team independence with enterprise-level concerns. Interested in talking with some of our architects about implementing good architecture practices? Reach out to us at findoutmore@credera.com.

Haven’t read part one or two? Check them out here: