5 unexpected ways to improve your architecture team

When my team started looking for ways to accelerate delivery of our hybrid cloud platform, I found inspiration in a surprising place: the manufacturing industry. Here in the CIO division of IBM, my team is building a hybrid cloud platform on IBM and Red Hat technology to transform our internal application portfolio, increasing the development teams' modernity and agility.

[ Get the Hybrid cloud strategy for dummies eBook. ]

In this article, I'll discuss the strategy behind adopting manufacturing industry concepts and applying them to the cutting-edge world of hybrid cloud platform delivery. I'll also share the benefits of this implementation, lessons learned, and the resulting changes made in adopting our Integrated Platform Team model.

Own the critical supply chain

I borrowed the concept of vertical integration from the manufacturing industry, where a manufacturer directly owns the most critical elements of their supply chain. This minimizes dependence on outside entities that may introduce risk due to delays or suboptimal output. The hybrid cloud platform teams own and are responsible for the most critical software-defined elements of the hybrid cloud infrastructure and services that make up our platform, including the architect, engineering, operations, and delivery management talent necessary to build and run this important service.

In Team Topologies, Matthew Skelton and Manuel Pais define a platform team as "a grouping of other team types that provide a compelling internal product to accelerate delivery by stream-aligned teams." A stream-aligned team (such as our development teams) focuses on a single, impactful stream of work. It can be a single product or service, a single set of features, a single user journey, or a single user persona.

[ Learn how to build a flexible foundation for your organization. Download An architect's guide to multicloud infrastructure. ]

Create independent, yet interdependent, functions

I separated the hybrid cloud platform team into three primary components (or chapters): Architecture, Engineering and Operations, and Delivery Management. While independent and autonomous in their own right, these discrete chapters provide a series of checks and balances that allow the team to increase velocity in a way that is consistently aligned with overarching strategic imperatives.

I also created two secondary (but equally important) components: a Security Focal and a Data and Analytics squad, which is a subset of the architecture function. The Security Focal is a member of the Hybrid Cloud Center of Excellence and is responsible for (and empowered to take action for) prioritizing security considerations across the platform lifecycle, from the earliest brainstorming and feature proofs-of-concept to implementation and beyond.

The Data and Analytics squad is led by a people manager member in the Architecture chapter, but it is organizationally aligned at the top rather than serving a subcomponent of another function within the Integrated Platform Team. The team is designing for data integration and analysis and decision-making at every level of the stack, and this squad aligns all the squads within the platform team.

The Security Focal and Data and Analytics squads help make data and security core competencies of our organization. What the other functions are doing is baked into everything.

The Delivery Management function is responsible for developing and tracking objectives and key results (OKR) across the unified platform team. It aligns everything the team is working on every day with a roadmap and, by extension, the larger CIO Hybrid Cloud Platform organization's overall strategic imperatives.

Build a unified strategic roadmap

One of the clearest benefits of this vertically integrated approach is that, for core platform functionality, all squads align their goals with an overarching strategic vision. This avoids having to negotiate with other parts of the organization, which have their own strategies and priorities to juggle. It allows the team to focus on delivering the core platform functionality efficiently and in an automated way. This saves time and effort that might otherwise be spent on negotiating for higher-level, "higher-value" services and capabilities.

Another benefit of bringing these functions under a unified strategic roadmap is that our Delivery Management function can more seamlessly apply the "big picture" to individual squad sprint ceremonies and work as a team to ensure alignment when sprint work crosses functional lines. With such wide visibility, the Delivery Management squad can more easily align priorities and objectives with other strategic functions in the CIO Hybrid Cloud Platform organization, such as Datacenter Services and Monitoring and Event Management.

[ Learn best practices for implementing automation across your organization. Download The automation architect's handbook. ] 

Collaborate by design

A key consideration for large organizations is ensuring that no major component can function with complete autonomy or in a silo. You don't want a squad to be incapable of getting things done without any input from other squads. Quite the contrary, for minor decisions or implementations, each squad is empowered to move as quickly as possible.  For major decisions with little or no recourse to make changes later, collaboration is key to the "measure twice, cut once" approach to critical decision-making. This enforced "checks and balances" means that no one chapter can unilaterally stray too far outside our strategic bounds.

At a lower level, the Delivery Management squad team members work within other squads but all report to the same manager. Embedding them within other teams helps make every squad's activities as consistent as possible. This allows minimal impact on sprints when, for example, a delivery manager is out on leave, because process alignment is a goal within the Delivery Management function. When key processes don't differ much between squads, any delivery manager can cover for another to keep day-to-day processes running smoothly.

Iterate the evolution

No major organizational change is perfect from the onset, especially one as dramatic and wide-reaching as the Integrated Platform Team. I make allowances to adjust the plan as needed, following true agile principles. When things aren't working as envisioned, I analyze the problem and adjust quickly.

For example, initially, the team created a decentralized platform support model, but we quickly realized that it was not providing the desired quality of service to end users. The team created a new cloud-enablement architect role and sought a full-time software engineer and a content developer. While organizationally part of the CIO Hybrid Cloud Center of Excellence, by having the cloud-enablement architect aligned with the Architecture chapter and reporting to the top, you "bake in" end-user support to everything that is done.

These roles focus on support automation by implementing IBM Watson Assistant technologies to intelligently direct end users to the appropriate support materials to resolve their issues. I envision this support automation will become more sophisticated over time, so fewer support requests will require a human member of the platform team to address them. IBM Watson Assistant seamlessly integrates with existing content management tools, such as Box and GitHub, and support interfaces, including Slack and our custom hybrid cloud portal. The cloud-enablement architect also owns the end-to-end support experience for end users—everything a user sees from the moment they realize they need support to when their issue is fully resolved.

[ Check out Red Hat's Portfolio Architecture Center for a wide variety of reference architectures you can use. ]

Another example of adjusting the plan to fix problems is the Security Focal, which did not exist in the organization's initial iteration. The team created it when it discovered unmet needs around alignment with IBM's internal IT security standards. It also gave the team a front-row seat to drive security in all platform development efforts up and down the stack.

Finally, I learned that it's better to make expectations clear at the outset of an organizational change. Each chapter needs to understand their various inputs and outputs. The initial approach was to set a high-level direction and allow things to evolve organically. This proved to be a bit confusing, particularly after management changes, so the team is working to document those inputs and outputs in a more formal RACI matrix.

Focus on what's most important

You might be thinking, "duh, I work in a large enterprise IT shop, of course it's easier to deliver when you own everything you need." Fair! But the real value isn't in "owning everything." It's about helping a large organization move smoothly in the same direction, collaborating around the most critical decision-making, and streamlining platform delivery. This enables brilliant architects, engineers, and delivery managers to focus on providing true value-adding features and services beyond the runtime to the stream-aligned teams that are seen as a critical part of their hybrid cloud transformation.

---

This is adapted from Lessons from manufacturing: A vertically integrated approach to hybrid cloud platform delivery on Hybrid Cloud How Tos and is republished with permission.