The Digital Transformer – Agile is Killing the Center of Excellence

This column started off with a bang. Last time, I chose the title “Is Agile killing EA?” and while there wasn’t a lot of discussion here, a gentleman named Jason Bloomberg posted a link to it on a LinkedIn discussion group that generated a lot of discussion.

(Note, I said last time I was going to write on “EA as waste reducer.” I need to stop making commitments like that, as I write best when I just go with whatever is at the front of mind.)

I’m doubling down in this column. While I believe that the *practice* of enterprise architecture will survive (for reasons I gave in my last column), there is no question that organizational forms are changing. In particular, the so-called “center of excellence” seems to be – based on multiple reports I am receiving – under serious pressure, if not hastening towards its end.

What is a center of excellence? Two of my first roles were in centers of excellence, with widely varying scopes. The first was focused on ERP software and was essentially an entire delivery center for a large consultancy, capable of deploying large, multi-skilled teams focused on the end to end delivery of a major ERP system. I’m not talking about this kind of COE.

The second role was in an architectural COE focused on data architecture, data modeling and data governance. This functionally focused, shared-service COE was in existence for at least 15 years, but was disbanded this year according to reports I am hearing.

Ultimately, it doesn’t surprise me that this happened. There was always friction around the governance that this team exercised over a critical resource (access to persistent data storage), and we found ourselves on the critical path more times than I care to admit.

I have seen internal centers of excellence (sometimes front-ended by “service catalogs”) for:

  • Project management
  • Business analysis/architecture
  • Quality assurance
  • Enterprise architecture
  • Data management
  • Enterprise integration
  • Innovation
  • Infrastructure engineering

While some may have more staying power than others, I am not optimistic for any of their survival long-term. The question is, why is this happening?

The idea of organizing work by functional skill is an old one. Production would flow through

  • Forging
  • Cutting
  • Stamping
  • Machining
  • Welding
  • Painting
  • QA

and to some extent this persists today for good reasons.

It’s not surprising that the first few decades of industrial IT sought to emulate this model, with systems development “work” being routed through analogous centers. Project Management COEs defined the method of flow and enforced it through their ownership of the project management resource. Project managers orchestrated the resulting work and applied pressure to drive it through the functional silos. Analogous to a manufacturing production model, a typical IT flow might pass through:

  • Chartering
  • Requirements (perhaps COE-based)
  • Analysis & design (some parts COE-based)
  • Construction
  • Testing (some COE-based)
  • Production

Many models existed. Sometimes the COE was primarily a home for functional resources who would be fractionally allocated to project teams; in other cases, a ticket-driven shared services model would be used. In either case, dysfunctional frictions and handoffs could easily emerge, and important, valuable work with a high cost of delay could be blocked.

And whether you owned a machine tool center in an industrial facility, or a QA center of excellence in an IT shop, you sought to optimize your function locally. Often, this was done by imposing burden on the upstream work center, by increasingly stringent standards for what would be accepted. Local optimization led in case after case to sub-optimal overall flow, and management by “who screams loudest.”

But even as this model (accompanied by a supporting “waterfall” methodology) was being instituted for IT systems development worldwide, the basic premises were under fierce questioning. The initial stirrings started years ago, in the origins of Lean thinking and works like Eli Goldratt’s The Goal (the inspiration for The Phoenix Project).

In 1991, right around the time many functional centers of excellence were being formed, Preston Smith and Don Reinertsen published Developing Products in Half the Time. In that work, Reinertsen continued his ongoing exploration into the challenge of product development, making the following observations:

“In general, we find most companies inclined to organize … around functional skills. The mechanical engineers are grouped together, as are the electrical engineers and the software engineers. … Our experience suggests …[i]f we organize around physical or logical subsystems … we tend to get much faster development.”

“One of the biggest problems we see in team design is the fragmentation of team member time among too many projects… managers underestimate the difficulty of making a fragmented team work… As a rough rule of thumb, assume that the less work someone has to do on your project, the more likely they are to be a delay on the critical path.”

Reinertsen is an interesting source of insight for IT systems professionals. A polymath naval officer trained as a nuclear engineer at the Naval War College, and later a McKinsey consultant, he is not an IT professional per se. Yet he is one of the most influential voices in Agile, widely cited by many of the most well known Agile thought leaders. He was instrumental in David Anderson’s development of Kanban, and his influence on the Scaled Agile Framework is also apparent.

He offers a systematic, well quantified, Lean approach to the broad topic of Lean product design and the processes and practices enabling its flow. Note that Lean has always had two faces: production (the assembly line) and product development (how the assembly line comes to be).

There is often concern among software and IT professionals that manufacturing insights (including Lean) are inapplicable to IT management. However, it is principles from manufacturing production that are hard to apply to IT & systems development, because IT systems development is not repeatable, and production is all about repeatability and minimizing variation.

When we turn to product development – whether based on biotechnology, materials science, electrical engineering, or software-based systems – we see common themes:

  • higher levels of variability in the process
  • a need to optimize for information generation (product development is the generation of information)
  • a corresponding requirement for fast feedback, as answers are not known in advance

In short, product development is always an iterative, uncertain, and risky process. There is nothing unique about software and IT in this respect.

What is unique in the current moment is the sheer, accelerating demand for IT-based systems and products. The transition to a product-centric orientation (for both internal as well as externally-facing IT) is now well under way, accelerated by phenomena like Cloud and the insatiable hunger of the modern economy for an ever-increasing digital component of ALL products. The demand for fast digital time to market is driving out older, less efficient, functional models, and that means the COE.

The concerns that gave rise to the COE model don’t go away. In the Spotify model, functional excellence still has a place and is promoted through the concepts of chapters and guilds. These are not merely advisory; they have some policy authority when matters of consistent functional approach are critical.

And finally, as with any large scale transition, this is contradictory and uneven. IT shops are complex adaptive systems, and there is much investment in the current model. Many organizations will continue to use COEs. Perhaps flow through them can be improved – prioritizing based on Cost of Delay is a promising approach, one I hope to explore further.

Share

submit to reddit

About Charles Betz

Charlie Betz is the founder of Digital Management Academy LLC, a training, advisory, and consulting firm focused on new approaches to managing the “business of IT.” He has previously held positions as enterprise architect, research analyst, developer and product owner, technical account manager, network manager, and consultant. From 2005-2011 he was the VP and chief architect for the "business of IT" for Wells Fargo, responsible for portfolio management, IT service management, and IT governance enablement. He has also worked for AT&T, Target, Best Buy, Accenture, and the University of Minnesota. As an independent researcher and author, he is the author of the forthcoming Agile IT Management: From Startup to Enterprise, the 2011 Architecture and Patterns for IT Management, and has served as a ITIL reviewer and COBIT author. Currently, he is the AT&T representative to the IT4IT Forum, a new IT management standard forming under The Open Group. He is a member of the ACM, IEEE, Association of Enterprise Architects, ISACA, and DAMA. Currently, he serves on the board of the Minnesota Association of Enterprise Architects chapter and is the organizer of the Agile Study Group, a working group of local practitioners and faculty examing Agile methods from the perspective of theory and pedagogy. Charlie is an instructor at the University of St. Thomas, and lives in Minneapolis, Minnesota with wife Sue and son Keane.

  • Steve Bell

    Hi Charlie

    Nicely done, but I feel like you dropped off the argument at the end

    If anything, COE’s in the Spotify model (chapters and guilds) gain importance,
    since there is a need for standardization and consistency among the various
    dimensions for things like EA, PMO, continuous improvement and so on. Otherwise
    they’ll tend to drift over time creating excessive, unnecessary variation,
    while not scaling and exploiting innovations that emerge in individual teams.

    The center of gravity,and learning, occur in the teams themselves. You could say
    that the experts in the COE continuously formulate the shared standards and
    practices, which are then tested by the teams, which provide feedback to the
    experts and the COE which spread new standards and practices laterally back to
    all teams. In Lean lingo this is known as Yokoten, or horizontal learning.

    In an agile enterprise where more ownership is distributed, and there are fewer
    ‘experts’, there is nonetheless a need for expertise to guide the future vision
    and capability development of everyone.

    The COE becomes an expertise matrix overlaid on the customer/product centric model to help drive organizational learning and innovation.

    Does anyone have another model that works?

    Steve Bell

Top