Roundtable: The Role of Enterprise Architecture in a Cloudy World

Do enterprise architects still matter? Has a cloud-native development model—not to mention a DevOps and SRE approaches to operations—fundamentally changed how we think about enterprise architecture? InfoQ wanted to learn more about this topic. We reached out to four architects to find out if a cloudy approach to software has changed their thinking. Our participants in this roundtable include:

• Brian Chambers, an Enterprise Architect at Chick-fil-A.
• Kent Weare, the acting Managing Director, IT for TransAlta.
• Ian Sutcliffe, an experienced enterprise architect working at a European company.
• Dan Young, currently CEO of UK consultancy EngineerBetter.

InfoQ: At this point, is "enterprise architecture" synonymous with IT architecture, or do you still see enterprise architects who focus on designing the business itself? What's today's enterprise architecture look like?

Kent: Yes, I do see Enterprise Architecture as synonymous with IT Architecture. In my opinion, to be in Enterprise Architecture you should be reporting outside of IT. Most architecture groups that I see are more IT focused. Now this isn’t to say that they are not looking out for the best interests of the enterprise, but their core responsibilities are the IT systems that support business processes as opposed to truly being focused on architecting the business processes itself.

I do feel there is a relationship between the size of the organization and the level of ‘Enterprise Architecture’ that is being performed. The organizations that I have worked for are typically between 1000 and 3000 people. Within these organizations, there has not been an Enterprise Architecture group that reported outside of IT. While these architecture teams have been called Enterprise Architecture teams, I have always felt they filled the role of IT or Solution Architecture.

In today’s Enterprise Architecture domain, there is a challenge in showing value. Enterprise Architecture can be difficult to measure and as a result, teams struggle with being relevant. Unfortunately, people tend to end up in EA roles as a result of what they previously were good at. With the change in dynamics between business and technology, I fear this relevancy challenge will only become more difficult to overcome unless people start making some fundamental changes in how they adapt to new ways of delivering IT services.

Ian: There is a philosophical, bordering on religious, debate within the industry on this topic, but I would say Enterprise Architecture is indeed synonymous with IT architecture at this point.  This is only natural considering the IT roots of EA. However, I would say that an EA who remains purely focused on IT is not really doing EA. One of the main values of EA is being able to bring the business and technical architectures together and propose and optimize change which spans both domains. I rarely see an enterprise architect working purely on designing the business itself but I do see them working on business design in conjunction with technology design. I believe both domains need to be considered as a whole to provide the most value rather than one leading the other. For me an EA function takes a major maturity step forward when it embraces business architecture and I think more and more of today’s EA teams are reaching this point.

Brian: There is a lot of value in having a cohesive technology strategy across the business. This doesn’t happen by accident; the path of least resistance often leads to silos that limit business agility at best or create a giant mess at worst. To achieve this cohesion, a group of people need to sit in roles where they do a few things very well. First, understand the businesses and its objectives. Second, understand IT’s current technology capabilities. Third, understand the impact of emerging technologies. Really understand them… how they work, what’s real and what isn’t. Fourth, drive change. Not just technically, but organizationally and strategically. Not just in IT, but in the business. To do this takes a person uniquely positioned, a person that can code with a developer one minute and talk to a business leader the next. 

In our organization, this is the role of an Enterprise Architect. We also look to build platforms/ecosystems that are relevant across business units, enabling the business to move rapidly with confidence. Examples of this are a self-service data access/analytics strategy or a foundational Internet of Things (IoT) platform. We deliver platforms, simple and lightweight rules-of-engagement, and then invite the business to participate in the resulting ecosystem. These are technology solutions but they are driven directly by business objectives. When it is working well, the EA role sits right in the middle of business strategy and IT strategy. 

In contrast, I see IT Architecture as answering the question “how do we get things done in IT” or “how do we solve this problem”? In our organization, we have pushed a large portion of IT Architecture responsibilities - the choices about solutions, tools, processes - to our DevOps teams with a high rate of success.

Dan: I certainly haven't encountered the EA role outside of Enterprise IT or software development. In the financial services enterprises we've worked with, I think today's EA still finds themselves being largely a gatekeeper, keeping everyone within a set of constraints. 

This role has its roots in the era of command and control management, so much of the EA context in very large regulated industries is still predicated on change being costly and difficult. However, the shift to a cloud native world is challenging that notion and placing new demands on them. The ideal role for an Enterprise Architect today is to be leading change, focusing on business outcomes and working at a level where they're able to join the dots between common problems in different teams.

InfoQ: Some enterprises are copying the "cloud natives" and moving to all-inclusive, cell-based team structures that prioritize velocity and customer experience over silo efficiency. Does that change the role of an architect? How do they participate in these product-oriented teams?

Brian: We are using this model in our DevOps practice. Each team has all the resources they need to design, deliver, and operate a product. This includes the Solution Architect role. The product team benefits from having complete ownership of their solution and more autonomy. 

Enterprise Architects can add value to these teams by:

• Knowing their technology stuff 
• Being a technical resource for teams on problems/patterns/architectures (current and emerging)
• Communicating wider organizational context to teams and connecting teams in collaborative environments, like Spotify’s guilds
• Promoting (but not mandating) consistency of approach to common problems

In our organization, the Enterprise Architecture team drove the organizational design and delivery of the DevOps model along with our move to Cloud Native solution delivery, and we helped with hands on delivery with the first several teams/products.

Ian: I don't believe this move fundamentally changes the role of the Enterprise Architect.

Part of the EA role is to understand the Enterprise Architecture (noun) and manage its evolution. An Enterprise Architecture is a complex system of systems and our view of that system was course grained application centric and change was project centric. Now our view is more customer centric and fine grained around “products” made up of containers and (micro-)services and change is more like a continuous stream of feature enhancements.

Before we segmented large enterprise architectures vertically along functional boundaries and horizontally along technology boundaries. Now we segment vertically more around the customer and think more along the lines of products and services and the horizontal segmentation doesn't necessarily go beyond the product boundary.

So, an EA still needs to manage a complex system of systems, but one made up of different types of building blocks and segmented along different boundaries. What changes is the knowledge required, the design paradigm, architecture principles and the governance approach.

Kent: I think it is important to make a distinction in regards to the term architect in this question.  Is there a role for an architecture in these teams, absolutely. I am just not convinced that they are as focused with enterprise concerns.  Part of the design of these teams is to reduce external (to the team) dependencies in lieu of focus, speed and autonomy.  But, there is still a place for Enterprise Architecture in areas of oversight, governance, managing technology sprawl, ROI and organizational change management.

Ian: I see your point. I assumed this question followed the first and so we were still discussing an Enterprise Architect and the impact on that specific role from the influence of the “cloud natives”. In particular, I’m thinking about my own experience helping a big corporate IT organization change its operating model and how the EA role basically moved from managing a portfolio of applications to a portfolio of related services/products. This is still an ongoing journey for us and we don’t yet have dedicated resources aligned behind each product, more behind groups of products.

Brian: I agree that clarity of "architect" is critical - if we're talking about solution architecture, it can sit with a product focused team. We're two years into making that transition. 

If we're talking about Enterprise Architecture, the role change is similar to what you described. I think the key is that there is still a place for EA to engage with the business on strategy AND with the product teams as a knowledgeable technologist, but with an eye for concerns that cross the organization. 

Dan: At EngineerBetter, we seek to build these types of product teams in the customers we work with. These XP or Pivotal-style teams consist of a Product Manager and pairs of engineers. In this environment 'architect' is considered a verb, not a noun. The right design emerges through the process of actually building the product, learning and adjusting the architecture as you go. If you were to view this team in isolation, you might argue that the role of Architect is no longer needed. However, as enterprise's difficult history with agile shows us, the interface between this team and the folks around them is crucial. So, an Architect can play a very valuable role in understanding the technical boundaries between product-oriented teams, providing guidance to business leadership, spotting problems and finding opportunities. Since EA's usually have a lot of history and domain-specific knowledge, they can also collaborate with Product Managers to reduce friction, identify needs and create better relationships with customers and stakeholders.

InfoQ: We purposely didn't label the "architect" type in the previous question to see what would happen, and your answers reflected that! Does the need for *Enterprise* Architecture change based on an org's maturity or whether or not they are trying to become a cloud native? Do expectations evolve as a company becomes more "cloudy"?

Ian: In my head, there are two facets to this. There is the role of EA during the transformation and then the role of EA when we have product lines in place.

Moving from "cloud immigrant" to "cloud native" is a big organizational and technical transformation.  This is the bread and butter of a good EA function. I don't see the role here much different than today - we're just doing EA on ourselves.

Then I think it's a question of how "cloudy" an organization is or wants to be.

I can see if everything was product based and autonomous then EA's role changes, or rather reduces. EAs might not go as deep as today but will focus primarily on governance and looking ahead for the next product.

However, I'm not sure any large scale corporate IT organization is going to be completely "cloudy". They're too attached to their monolithic ERP systems.  So, I think there will still be a lot of shared technologies and a complex landscape to manage which is again the realm of EA today. Perhaps there's a mix of autonomous customer centric products which need the agility and then core IT, i.e. we accept bi-model IT.

I think what I've concluded, at least in my head, is that a good EA will still use the same skillset and have a job no matter how cloudy it gets!

Brian: I agree with Ian. The EA role is critical to driving technological and organizational transformation, so it is critical to becoming cloud native. Many classic paradigms must be re-thought, tools and frameworks discarded, responsibilities changed. It’s not easy and it does not happen well by accident. As the organization becomes more cloudy the EA role may shift away from its disproportionate and explicit “cloud focus” and onto the another major disruptor. That said, cloud is never “done”. New architecture patterns emerge. New cloud platforms and tools are built. New services are released rapidly. EA needs to keep tabs and align emerging tech with business opportunities. At the end of the day, EA needs to ensure that the rate of internal change (tech and org) stays on pace or ahead of the rate of external change [Welch].

Kent: Yes, the role of an Enterprise Architect (EA) is still required as an organization transitions into the cloud.  Many of the same principles around risk, governance, business value and technology sprawl still exist regardless of the environment.

I do think expectations evolve.  An EA is in a position of influence. If product, or project, teams working with the EA don’t see value, or feels the EA cannot relate to the current landscape, they will look to avoid, or workaround, the EA. As a result, the Ivory Tower Architect emerges.

Dan: Yes, absolutely, expectations of the EA role change as organisations seek to become learning organisations, which is how I would translate this. Some of the traditional EA concerns remain, but some of the working patterns dissolve. To become more 'cloudy' is the same as saying that you are removing the cost of change from infrastructure and services. To leverage this, you need a philosophy that embraces change and a style of management that is adaptive rather than command and control. So, the EA, and indeed the entire Project Management office, should be getting used to adopting a mindset of continuous improvement. Rather than lots of up front effort, planning and design, the new philosophy will be: let's build something that actually works, put tests around it, and then iterate. In this example, an EA will be expressing their needs as tests that can continually assert that security and compliance needs are being met.

InfoQ: The cloud ushered in new technologies, tools, and patterns. Can enterprise architects be trusted to define standards or approve application architectures without first establishing a deeper base of knowledge about cloud? Should enterprise architects code, and be users of the technologies they advise on?

Ian: Enterprise Architects become the guardians of the standards but do not work alone in defining them. We have a defined process to move new technology from the tech watch list, through a PoC and into prime time. Industrialization is often where things fall apart so only once there is sufficient organizational maturity behind the technology does it become a standard.

EA’s involvement in this process may vary by organization. At a minimum, they are bringing in the business dimension to assess how this technology can help the business/customer. They assess how the technology may fit into the rest of the landscape.

Whether EAs should be coding probably depends on the organizational size, culture and the abilities of the architect in question. EAs may be involved in the PoC and actually cutting code to establish Solution Building Blocks for future use or that may be done by a technical architect aligned with the appropriate technology domain. I personally find it valuable to have some low-level insight and I still like to code PoCs, but I’m sure many would prefer I didn’t :-)

Dan: Yes, it definitely helps but deep technical knowledge acquired in a different context can also be dangerous. I think that the main reason for EAs to have practical experience of the technology would be as a means of building trust with the engineers on whom they are imposing constraints. With this in mind, the best way of building empathy in both directions would simply be for them to rotate through the teams with whom they work. I would highly recommend all EAs to just take a day off from meetings to just work the backlog and do some pair programming. I guarantee you will feel Zen!

Brian: I do not think Enterprise Architects can be effective in defining technology tools, patterns, or standards unless they use them hands on. There needs to be a regular cadence of diving deep into the details, and then an emerging to define strategies based on what’s real. You must retain the ability to code. You must be able to get your hands dirty on POCs with new technologies. You probably don’t want to be in the critical path of real delivery, but you should be capable of doing so. This garners respect from product teams, facilitates real technical dialogue in the organization, and keeps architecture patterns fresh. This makes EA a challenging role, but extremely engaging and rewarding. I think a successful EA is deeply curious about business and technology and is passionate about seeing great solutions built.

Kent: I really like an analogy that Gary Vaynerchuk, digital strategist and CEO of Vayner Media uses when he talks about disrupting traditional marketing practices using social. The idea is that people need to spend time in the “clouds and dirt”. I think there is a lot of applicability when we talk about disrupting traditional IT. When someone is “in the cloud” they should be focused on vision, strategy and mission. “The dirt” is being a practitioner and understanding the details in order to actually execute on the strategy. The key, is to limit activities anywhere in between.

I think this analogy aligns well with Enterprise Architecture. In order to avoid becoming “headline readers” about transformational technologies and truly being effective, one needs to be able to execute at both ends of the spectrum, to provide value. 

To bring this back to the question at hand, architects should be spending some time coding, or in the dirt, in order to understand and validate the technologies they are including in architectures. Otherwise, how do they know if it will work? Because they read a vendor whitepaper?

The challenge, in my opinion, is to not spend disproportionate time at either end of the spectrum and this where it may be difficult for architects. It takes a tremendous amount of discipline and talent to be able to do this. 

InfoQ: What advice do you have for companies hiring enterprise architects today? What should they be looking for, and what should they de-prioritize? And what advice do you have for enterprise architects who are working inside companies making a cloud transition?

Kent: Organizations should be questioning everything about traditional Enterprise Architecture. I really think organizations need to focus on value and ask themselves "how does producing this artifact provide value?" If an artifact can easily become stale, should we even be producing at all? Is this better reflected in a dynamic tool?  I also think people need to focus on outcomes and stop rewarding others for building strategies. A strategy is useless unless it has been executed.  

Organizations should be looking for people who have an innate sense of curiosity, have both soft and technical skills, are capable of leading and coaching and are willing to get their hands dirty every once in a while.  As organizations transition to the cloud, enterprise architects need to embrace this change, ask the right questions and become champions for the organization. The cloud is here, you might as well embrace it.

Ian: For companies embarking on a transformation program, then architects with experience in some kind of transformation program is a minimum. If the transformation was of the IT organization itself, good. If the target IT operating model was towards a more service/product centric organization then great. If those products and services were based on cloud technologies, hire them on the spot.

For companies who have already made that shift to cloud-native then you want forward looking architects that are good at understanding and assessing new technologies but also have very good business acumen. They need to understanding the business direction and evolving needs of their customers so they can assess the applicability of new technologies and apply them to existing or new products. Then you’d want some experience in actually bringing new technologies into the organization.

De-prioritize certain technology skills typically associated with core IT and infrastructure.

For those enterprise architects inside companies already making a cloud transition, talk with your peers in other companies to gain insights. Look into and assess applicability of reference architectures like IT4IT. Completely understand the target operating model or preferably help define it. Understand the current and emerging cloud technologies, assess applicability then propose and get involved in PoCs to prove them out.

Brian: Companies that are hiring EAs today should look for a person that can run the gamut, from writing code and “proof-of-concepting” new technologies to driving strategy alongside business leadership. Recent hands-on, technical experience and a track record of influencing leadership are critical. An ability to mentor technical talent is important as well. Most of all, look for a curious, continual learner that will always be asking “what’s next?”.

For EAs that are making a cloud transition right now: 1) Get hands on with cloud technologies. If you don’t, you won’t know how to effectively advise your organization on the impact of cloud. 2) If you have not developed lately, do that too. 3) Get buy-in from your security team; doing so changed the game for us. 4) Realize that the technology is the easy part, and the organizational changes are what’s going to be the biggest challenge. Start bringing people along from day one.

Dan: Some traditional skills still apply, such as an aptitude for context switching between teams’ business scenarios. In terms of new skills, I agree with Kent - I'd advise companies to look for people seem able to focus on outcomes, rather than the activity of architecting things. The other crucial skill is an appreciation for continuous learning. You uncover a lot of obstacles when you start trying to implement new ways of working. At EngineerBetter we often joke about finding the 'rakes on the lawn' when starting with a new team or customer. A shift towards cloud native thinking will reveal these obstacles, but it won't solve them. Companies should be de-prioritising the usual 'up-front' planning and design skills associated with architects, but this should be combined with empathy to avoid collisions between waterfall and agile philosophy.

An EA today can find themselves in a potentially volatile environment, in organisations struggling with change. They need to switch between the mindset of a diplomat, lawyer, lobbyist, software developer, product manager. If you're an architect who knows there is a better way of looking at the problem, don't be afraid to lead when it seems like nobody else is. The goal is to create a critical mass of better behaviour; a movement of leaders that creates more leaders.

About the Interviewees

Kent Weare is currently the acting Managing Director, IT for TransAlta, a power generation and energy trading organization.  Prior to taking on this role, he led the Enterprise Architecture and Integration team at TransAlta.

Dan Young has worn a variety of hats over the last 15 years, spanning engineering, presales and product management and is passionate about seeking to understand and resolve organisational friction. He is currently CEO of the UK Cloud Foundry consultancy EngineerBetter, who have worked with software teams in enterprises across global banking, wealth management, FTSE 100 retail and software vendors.

Brian Chambers is an Enterprise Architect at Chick-fil-A in Atlanta, GA. He focuses on delivering new platforms and capabilities like Self-Service Analytics, Cloud, Internet of Things to the business. Most recently, he has been focused on building out a cloud-native, DevOps delivery practice. He also spends time researching and understanding emerging technologies and finding ways to integrate them into Chick-fil-A’s technology strategy.

Ian Sutcliffe is an experienced and enthusiastic Enterprise Architecture leader with over 20 years of experience in strategic planning, governance, technical management, leading strategic architecture projects, solution design and delivery and the maturation of Enterprise Architecture functions. A perpetual student of the Enterprise Architecture disciplines, proud generalist and skilled in numerous technologies.