Business Alignment Alone won’t cut it Anymore: A Proactive Approach for Enterprise Architecture in the Digital Era
How Enterprise Architecture should recognize enterprises as complex systems and act accordingly
Keywords: digital transformation, enterprise architecture, agile methods, complex systems
Since Enterprise Architecture became more prominent, it’s been somewhat a relationship of love and hate with the business. It does help the company to find its way through organizing business strategy, the processes it defines and the technological capabilities which underlie them, but the way it was executed in a not so long past made business executives, for lack of a better word, skeptical.
Why should they? In most definitions of Enterprise Architecture found in the specialized literature, it is about the mapping of the entire enterprise capabilities, from the business imperatives, strategies, processes and people, down to the applications that support the business and the data by which it is represented, finally relating to the underlying technology infrastructure. More than that, it should assure that it is able to support the business and its model currently and in the future by providing a project-oriented, continuously-improving manner to assess its current state and evolve it as time and needs change.
As I used to joke about, “in a perfect world, a fully deployed Enterprise Architecture practice should allow the company to assess the impact in local revenue of a misplaced Ethernet cable”. Enterprise Architects should be at the forefront of a company’s decision making process, directly reporting to CEOs as advisors and being “secret weapons” for company growth. Once tightly aligned to the business, IT should be able to provide all that is needed to guarantee current operational stability and the fulfillment of future business demands.
So why is it not as common as it should be?
Glorified Documenters?
Business leaders grew aware of the fact that Enterprise Architecture can easily turn from a value-creating practice into a documentation burden if not well directed and made active from the start. This is not without some grain of reason. A significant amount of literature and conceptualization around Enterprise Architecture by some of the most popular frameworks (TOGAF, Zachman, FEAF and others) stresses about the importance of creating a solid understanding of the relationships between business elements within the company and its underlying technology and provide encompassing, methodologically sane documentation about it (the well-known City Planning approach). However, when it comes down to “make it happen”, showing its bottom-line value to the business, its practical aspects are treated vaguely and, maybe for being too concerned about not being forcefully prescriptive about its format and way of adoption, it lacks some direction towards actionable best practices.
Traditional Enterprise Architecture approaches also have the reputation of being too conservative and reactive. Lots of its responsibilities are directed towards the elaboration and governance of the main standards for the creation of new capabilities within the company, normally from the application, data and technology perspectives. The avoidance of prescriptiveness towards the adoption format, here, contrasts with the rigidity it proposes to apply to the technology adoption process as a whole. This normally places Enterprise Architects in the position of gatekeepers of the business-to-technology approaching principles and methods, which means that every new project has to be validated against those standards. While, if carefully managed, it fosters capability reuse and avoids the construction of IT silos, it may as well as slow down the innovation pace to a level unacceptable by the business.
On the other hand, the production itself of the commonly used architectural artifacts is a time-consuming effort. Most of the times, when the Enterprise Architecture team finishes creating an as-is snapshot of the current architecture state, which should be the basis for any further to-be initiatives, it is already outdated and should be reviewed all over again. That is to say, when a traditional Enterprise Architecture practice is “perfectly doing its job”, it may mean that it is aligned with the business strategy as it is right now, but not helping a lot about innovation and transformation in the long run. As Michael Vögele, adidas CIO, stated in 2017:
“[…] there was basically a statement that McKinsey gave us a few years back, that said: ‘Guys, you are really great! You have a highly industrialized, cost-efficient, one-size-fits-all IT’. When I started my job two years ago, I was looking at it and saying like, ‘Oh, my God, is that really what we want? Is that really how we drive the Digital Transformation, how we personalize, how we work with our consumers? Is this really what will be the value that we have at adidas as an IT organization?’ […] actually, this is not too bad, it actually fits exactly our old business strategy […]. But now we’ve changed. All of a sudden we are talking about consumer centricity, brand desire, being fast, changing the way how we interact with our consumers. “
Michael Vögele, adidas CIO, at the LeanIX EA Connect Day 2017
Also, a worrying number of architectural efforts and projects are directed towards the architecture itself, its documentation and communication plans. This may make Enterprise Architecture seem like an “autistic” practice, without connection with the real world of the business, and sometimes even of the IT organization.
Of course, that does not mean that all EA is or should be about is documentation and governance. Ross et al., in one of the most important books on the matter, Enterprise Architecture as Strategy: Creating a Foundation for Business Execution, are very clear and straightforward when talking about the foundation for execution of a technology-infused business and how EA helps executives to actively understand the better business operating model on which to build its strategic vision, to provide and organize the technology capabilities needed to support the model and to evolve its maturity from a Business Silo-ed organization towards a complete Business Modularity stage. Nevertheless, this is unfortunately an approach to EA that is not as widespread as we would like to be in many companies. According to MIT CISR (Center for Information Systems Research), the authors’ alma mater, Enterprise Architecture is defined as:
“[…] the organizing logic for business processes and IT infrastructure reflecting the integration and standardization requirements of the company’s operating model. The operating model is the desired state of business process integration and business process standardization for delivering goods and services to customers.”
Source: Ross et al., Enterprise Architecture as Strategy: Creating a Foundation for Business Execution, 2006
Another definition which is very consonant to the notion of Enterprise Architecture as an active force within the company’s strategic decision making is given by Gartner:
“Enterprise architecture (EA) is a discipline for proactively and holistically leading enterprise responses to disruptive forces by identifying and analyzing the execution of change toward desired business vision and outcomes. EA delivers value by presenting business and IT leaders with signature-ready recommendations for adjusting policies and projects to achieve target business outcomes that capitalize on relevant business disruptions.”
With that said, for Enterprise Architecture to be more engaged in the process of value creation, it has to leave its position of passiveness and take a more proactive stand towards business. It must encompass much more than plain old “City Planning”; cities which are “too planned” lose their ability to grow and adapt along the way. It has to be agile.
A Seat at the Table
Enterprise Architecture still suffers from a pre-digital way firms approached business and IT. Strategy was more stable, something to be planned with a great advance and be followed within the next 5 years or even more. On the other hand, Information Technology was seen as “bitter means to an end”, a necessary operational capability but one which would be always sipping money from the company’s bottom line without a correspondingly important reflex on the revenue. EA, then, was conceived as a way to control costs and complexity of IT systems; however, it grew to be an enterprise-wide view of the company’s IT, but didn’t take too much into account the business needs themselves. As stated by Tom Graves, Principal Consultant at Tetradian Consulting:
“So from the business side, there’s often a deep resentment at what’s perceived as the know-it-all arrogance of IT, and its apparent inability to deliver what the business believes it needs; and from the IT side, there’s often deep frustration that business ‘just doesn’t get it’, either in expectations or awareness of possibilities. It’s not a happy mix.
Enter, stage left, enterprise architecture. It’s initially sold to the business as a way for IT to bring its own house in order. And although business may grumble at the addition to the IT staff of yet another bunch of over-paid technical types who appear to do nothing, it does seem to work: costs and complexity do seem to come down. As long as those ‘architects’ don’t bother us, say business, everything’ll be fine.”
Tom Graves, Real Enterprise Architecture: Beyond IT to the whole Enterprise p.20
However, in the Digital Transformation era, IT is not just a means to realize business imperatives and models which are conceived separately from the technology, and whose role and duty is just to “be aligned with the business” in a struggle to prove its worth. New digital technologies such as mobile devices, Internet of Things, Cloud Computing, Machine Learning and Big Data, as well as methods of turning application deployment faster such as Agile frameworks like Scrum or Kanban, Continuous Delivery/Deployment and DevOps, established a whole new ground for the importance of IT for how the business model itself is built.
Success in the Enterprise Architecture endeavor, now, depends, of course, on the business acumen of its main practitioners, but also on the awareness of the architect about which and how new technological possibilities may be inserted in the new business models. While C-Level executives have been constantly pushed into accepting that the current state of affairs in the marketplace is changing to digital ─ and some, even most of them, have honestly committed to transforming their mindsets ─ they may lack the tech awareness or depth to absorb all the potential offered to the business by these new trends. Now Enterprise Architects have the responsibility not only for being reactive to executive strategic decision or to apply governance processes to the development of new capabilities, but also to be proactive in helping these executives to formulate new directions given the plethora of possibilities in a fast-moving way.
That means that Enterprise Architects have a lot more at stake when participating in strategic decision making. Just as the market changes rapidly, the underlying architecture ─ business and technological capabilities ─ should have the ability not only to provide flexibility for the new undertakings, but rest itself on a methodology that allows for its own quick review and evolution. More than that, fast-moving business systems should have their decision making as free as possible from rigid governance hindrances and quarter-long approval and follow-up processes.
The Need for an Agile Approach in Complex Systems: A Netflix Example
One of the main attributions of modern Enterprise Architecture is to be a steward and enabler of business and IT capabilities evolution. More than just establish a cycle of long-term architecture transformation, establish the agile practices for it to be able to keep pace with the rhythm of the Digital Transformation.
Let’s work with a simple example. Netflix has a huge need for a very flexible architecture. New business capabilities and digital content are added daily to a very complex, open-source-based, distributed system. Business has a need to accelerate its OODA (observe, orient, decide, and act) process, and having to wait for time-consuming steering committee and architectural compliance check meetings would not make it. At the same time, many of the controls and policies set with the intention to cut costs ended up preventing the company from saving costs and improving bottom- and top-line results. As Adrian Cockcroft, former Netflix Chief Cloud Architect, posed:
“Months of approvals cost more than the machine you asked for. When you optimize on cost, you slow things down, which increases costs elsewhere. Externalities often aren’t taken into account.”
Adrian Cockcroft, in Agile Enterprise Architecture Finally Crosses the Chasm
So Cockcroft and Netflix took a bold step and accepted the involved, non-centrally-controlled, almost chaotic nature of its business; as such, it demonstrates a self-organization which, if well driven, feeds its own growth without resorting heavily on a centralized control, fostering the right emergent behaviors — in this case, the creation and deployment of new products and capabilities, as well as their governance — while being able to react promptly to any non-planned hurdles such as architectural exceptions, project delays and resource shortage (the above mentioned externalities) and avoiding the chaos that may arise from such huge, complicated, highly connected environments.
Let’s recall some Complex Systems terminology. Hiroki Sayama, Director of the Center for Collective Dynamics at Binghamton University, State University of New York, defined some of the aforementioned concepts:
Complex systems are networks made of a number of components that interact with each other, typically in a nonlinear fashion. Complex systems may arise and evolve through self-organization, such that they are neither completely regular nor completely random, permitting the development of emergent behavior at macroscopic scales. Emergence is a nontrivial relationship between the properties of a system at microscopic and macroscopic scales. Macroscopic properties are called emergent when it is hard to explain them simply from microscopic properties. Self-organization is a dynamical process by which a system spontaneously forms nontrivial macroscopic structures and/or behaviors over time.
Hiroki Sayama, Introduction to the Modeling and Analysis of Complex Systems, p. 3–6
Adapted from: Carlos Maldonado, Nelson Gómez-Cruz, When Management Encounters Complexity, 2012
Bringing it back to the main theme, architecture’s major attribution, as described by Cockcroft, is to “[make] people do the right things without constraining what they build. At Netflix, my role as architect was to document, encourage, and evangelize architecture. For example, how we handled availability, disaster recovery, and backups.” Following an agile, iterative approach, supported by the Cloud, Mobile and DevOps-based architecture and methods, Netflix could drive fast product development across multiple teams, each of which is responsible for its own continuous delivery. To achieve such levels of fast response, architecture has to be fluid and enable for feedback loops and constant review of its capabilities:
“The architecture we created was an idealized version that we put out there to get feedback. The faster we learned, the better able we were to support efforts to transform the company. The agile approach means continuous course corrections.”
Adrian Cockcroft, in Agile Enterprise Architecture Finally Crosses the Chasm
So this is the big takeaway, and a paradox of some sort: for Enterprise Architecture to catch up with the needs of the digital age, and be more relevant to the business, it has to have a less restrictive and centralized governance proposition in its relationship with the executives and product managers, being instead more of an advisor of the business possibilities of the new technological trends, while providing the right basis for the information systems teams to “follow the flow” in the life cycle of the supporting IT capabilities. And, of course, as products and services are released more often and with less hassle, C-Level executives are happier, and more open to the Enterprise Architect’s advice.
Call to Action
So, what does it change for Enterprise Architects? The answer is: everything. Enterprise Architecture’s new duty is to seat at the same table as business executives, joining forces to weave a digital business model together. This demands a more significant knowledge of the business domain from the side of the architects.
They should not be those annoying guys (or ladies) to whom everyone roll their eyes in product and project initiation meetings and steering committees, thinking: “Here comes the showstopper!”, but someone who can attend such meetings saying: “Analyzing the new trends I have researched in the Internet of Things and Machine Learning fields, I see we should implement a new way to provide product recommendations to our customers and, by the way, our architecture and organization allow us to come up with a first pilot version of these functionalities in the next week; if it is well accepted, we can grow its scope incrementally.”
On the other hand, a new approach to understanding the interplay between information systems and the business has evolved from the ever accelerating need for innovation. Rigidity is out of question, so enterprises and their capabilities should be seen as they really are ─ complex systems where the main raison d’être for Enterprise Architecture is to foster feedback loops and coordinate the stream of the emergent behaviors, letting new capabilities be implemented as they are conceived.
As a conclusion, although many digital companies (especially those which were founded as digital businesses, not established firms which underwent transformation) ditch the idea of having a traditional Enterprise Architecture practice altogether, I understand that there is a number of principles and practices from related frameworks that could be utilized and revamped with agile and complex systems perspectives to help in the organization and formulation of a well-structured approach, providing freedom of creativity flow and new capabilities advisory while keeping a healthy level of control, which will be the subject of a forthcoming article.
About the Author
Sources and Bibliography
[1]: Jeanne Ross, Peter Weill, David C. Robertson: Enterprise Architecture as Strategy: Creating a Foundation for Business Execution, ISBN 978–1–59139–839–4
[2]: Marc Lankhorst et al.: Enterprise Architecture at Work: Modeling, Communication and Analysis, ISBN 978–3–642–01310–2
[3]: Tom Graves: Real Enterprise Architecture: Beyond IT to the whole Enterprise, ISBN 978–1–906–68100–5
[4]: Hiroki Sayama: Introduction to the Modeling and Analysis of Complex Systems, ISBN 978–1–942341–09–3
[5]: Carlos Maldonado, Nelson Gómez-Cruz: When Management Encounters Complexity. Documentos de Investigación, Escuela de Administración, Universidad del Rosario.
[6]: Jeanne Ross: 2017–20 Designing for Digital (Video)
[7]: Jason Bloomberg, Michael Fulton: Restarting Enterprise Architecture in the Age of Digital Transformation (Video)
[8]: Michael Vögele: LeanIX EA Connect Day 2017: Enterprise Architecture at adidas with Michael Voegele, adidas (Video)
[9]: Michael Cote: Rethinking enterprise architecture for DevOps, agile, & cloud native organizations by Michael Cote (Video)
[10]: Jason Bloomberg: Agile Enterprise Architecture Finally Crosses the Chasm
[11]: Jason Bloomberg: Is Enterprise Architecture Completely Broken?
[12]: The Open Group: The TOGAF® Standard, Version 9.2
[13]: Gartner Group: IT Glossary, Definition of “Enterprise Architecture”
[14]: Sven Blumberg, Oliver Bossert, Jan Sokalski: Five enterprise-architecture practices that add value to digital transformations
[15]: Oliver Bossert, Jürgen Laartz: Rethinking the technology foundation for digital transformations
