I was not sure if this controversial topic would come up in any of my readings, but after going through this week’s tasks, I came upon the teaching of standardization and integration as an operating model.  The dimensions alone do not come across as debatable, but when you take into account the actual process and stakeholders affected, they become more applicable.  According to a chapter by Ross, J., Weill, P., Robertson. D. (2006) in Enterprise Architecture as a Strategy, the key dimensions of an operating model involve standardizing and integrating.  Standardization in EA offers how business processes should be executed regardless of the team or person performing the process.  Integration in EA links the organization’s units by shared data.

The travel technology organization I work for shares a different thought on standardization.  Let’s start from about a year ago when we were trying to define our software development lifecycle.  We had a defined process but not a standardized one.  Every time we needed to develop a new aspect of our current product we had two approaches: The Developer side and The Product side.  Even though our product managers owned the decision-making piece, it was the developer team that estimated for us the time and dates of project completions.  Our SDLC was poorly written and executed by all parties that took an interest in upgrading our product platforms.  There were bottlenecks at each step, the right parties were never a part of the right conversations, and estimation and budgeting were always off.

Fast-forward a little more than a year and we have finally standardized this specific part of our operating model.  The integration aspect and flow of information have always been present, but we struggled to find the unification, coordination, and replication dimensions.  This process of unification has drawn a line in the sand between our development and product teams.  Since the organization has two business models (enterprise and community), our development team struggles with all of product’s centrally mandated initiatives.

As a product team, we have made decisions based in sum of our goals, initiatives, and strategy.  Development and product do not always see these from the same perspective.  A task as simple as writing a business requirements document has become difficult because of the constraints that our development team seems to think it places on their performance.  Up until recently, we did not have an accurate way to measure the deliverables from BRDs submitted and the progress in which the product team could convey to leadership that the development team was on track.  When our product operations director began the process of standardization, it was apparent that development had a tough time with having their progress being measured and scored.  Ultimately, the backlash fell on the product team and an unspoken barrier was formed.

I see this division in many organizations and some work better than others, but as part of a successful enterprise architecture strategy, sometimes you have to draw a line in the sand for players to realize what team they should be on.  I have always been on board with this level of thinking and not only has this allowed the product team to measure, compare, and improve on deliverables but has allowed us to redefine our strategy.

Ross, J., Weill, P., Robertson, D. (2006).  Enterprise Architecture as Strategy.  Creating a Foundation for Business Execution, Ch, 2, Ch. 3.