Blog Post

Cloud & the evolution of the enterprise architect

Stay on Top of Enterprise Technology Trends

Get updates impacting your industry from our GigaOm Research Community
Join the Community!

Enterprise architects have been a staple of corporate IT departments for well over a decade now, starting in earnest with the advent of service-oriented architecture and corporate data modeling. The need for enterprise architecture was spurred by the need to gain control over an increasingly complex computing environment, and an increasingly large backlog of data and feature needs. But those needs are changing, and so is the job of the enterprise architect.

The use of the term “architecture” in this context comes, in part, from the idea that one can create a “blueprint” for how a business can run on technology. The “architect” is someone who looks at the materials available, interviews the “client” (aka the business) about desired form and functional outcomes, and engineers solutions to meet those needs.

As the corporation is a multi-“client” entity, the enterprise architect has been increasingly tasked with reconciling competing requirements to efficiently achieve form and function across the enterprise as a whole. To do this, enterprise architects were (and are) often granted control over large parts of how data, software and infrastructure are organized to efficiently address the greater good.

There is no enterprise architecture

Enter cloud computing. As I’ve discussed before, cloud computing is creating an environment in which software components and data collections intertwine to create a complex adaptive system. What this means is that “control” over the design parameters of enterprise computing is starting to be highly distributed among cloud infrastructure providers, service operators and those that build and run applications on those services.

In the end, the idea of “blueprinting” an ideal solution for an enterprise’s computing needs just doesn’t work. Things move to fast. People make decisions completely independent of what your business objectives are (or are perceived to be). There are entire data schemas, messaging formats, API definitions, and even entire business processes that an enterprise relies on that will be out of an “architect’s” control.

But saying “there is no enterprise architecture” is a bit extreme, so let me temper that thought—slightly. There is no way to precisely specify the design, implementation and integration of complex cloud-based application systems. So the role of the enterprise architect is no longer building and maintaining a stable computing model for the enterprise. In the age of computing as a single, global, complex system, that role has to shift.

There’s only enterprise product management

To what? Clearly, there is the need for someone to watch over how individual applications, data sets and services evolve within the new world. There is a need for someone to guide the alignment of those software components with business needs.

In businesses that are themselves complex, there are tremendous efficiencies to be gained by the smart application of IT. That element of the enterprise architect’s role doesn’t go away.

What does change are the skills needed to evaluate how business applications, data sets and services are going to interact—and survive—in a complex, adaptive systems environment. If developers are the DNA of software in the cloud, the enterprise architect becomes the immune system, encouraging the growth of systems that help the business thrive, and killing those that would cost the business.

In this sense, my friend Brenda Michelson, a consultant specializing in enterprise architecture, put it best: the role is no longer one of enterprise architect, but rather one of the enterprise product manager.

How it works

In software companies, the product manager “owns” the success of the product: what market it should address, what capabilities it should provide to address that market, how it should be presented to that market, and so on. A product manager finds him or herself performing a constant blend of market analysis, product definition, business development and messaging.

Just as software product managers must constantly work to make their products thrive in its complex market ecosystem, so too must the new enterprise product managers constantly evaluate ways to make their business systems thrive in a complex computing ecosystem. Yes, there is still architecture involved, but it’s no longer the primary role. The primary role is management and analysis.

Is there governance? Sure. The enterprise needs to run as efficiently as possible while remaining resilient. However, forcing developers to use specific services and tools will likely give way to a better approach: creating killer shared services that everyone wants to use.

Is there design? Absolutely, though I would argue it’s different design in many respects. The complexity of application design in a cloud environment is around the relationships between components, not the components themselves.

Netflix's circuit breaker dashboard.

So, enterprise product managers should focus on how to design environments in which their products thrive. The system as a whole must provide support for resilient component integration. The “circuit breaker” pattern used by cloud-based companies such as Netflix (s nflx) is an example of this.

What there isn’t, generally, is an attempt to lock down exactly how business applications and data will act and interact system-wide. An enterprise product manager should be an expert in the concept of Observe, Orient, Decide and Act. And in the stability-resilience tradeoff.

One final note

Not all enterprise architects spent their days trying to lock down everything. Not by a long shot. However, the concept that complex systems can be architected, and we should strive to architect as much as possible, remains regardless.

I believe cloud computing is going to turn this on its head and create a world in which we architect some basic, simple mechanisms that make system-wide architecture both impossible and undesirable at scale. Then the magic of emerging behavior and intricate systems evolution will begin. That, my friends, will be an amazing thing to experience—and a new challenge to manage.

Feature image courtesy of John Grayson.

14 Responses to “Cloud & the evolution of the enterprise architect”

  1. The article is cleverly written to morph the role of Architect to a Manager.
    In my view, Cloud has only complicated stuff as in your blueprint/architecture, there will be lot of moving parts. The more you have moving parts, the higher the possibilities of complexity. The higher the complexity, you better have a control on it by having a map of the same. And the map is created by none other than EA himself.

  2. Brajesh Goyal

    Believe in the evolving world, there is a need for both an Enterprise Architect (a cloud architect) and an Enterprise Product Manager (or a relationship manager). Cloud architect designs the blueprints. Product Manager (or relationship manager) designs the product offerings to the IT consumers.

  3. Paul Calento

    Seems like there’s three views of the impact of cloud: The way to should be; The way we “think” it is; The way it really is … and there’s competing camps. One challenge impeding enterprise architecture, specific to the cloud, is reconciling rogue deployments driven by “shadow IT”. With a myriad of public cloud, private cloud and traditional IT assets out there, we need to manage this hybrid or converged cloud reality with a baseline of transparent management, security & interoperability. As for a design or architecture, perhaps we should look to open projects as a start?

  4. daniel_eason

    I’m disagreeing with this article and I am questioning whether you are right or wrong here.

    On careful thought I just cannot see such a morph occurring. Businesses will always need Architecture to ensure they select and create IT capability which meets the goals of the business and if lucky enough can assist in fulfilling the business strategy. Whether this is done with Cloud technology or Mainframe it’s irrelevant.

    If you’d said the Development role was morphing into a Product manager then i’d probably agree with you.

  5. Steve

    The “cloud” is an architected solution, EA is here to stay….computing does not occur in a cloud…it requires infrastructure, software networks….sounds nice to call it a cloud, but the design of hardware & software requires an “architected” solution and design process.

  6. Thanks for an interesting write-up on a highly relevant topic. I wonder if the evolving role of an Enterprise Architect is more like a Service Broker than a Product Manager. At the end of the day there has to be someone responsible to implement an IT System that meets functional requirements and features as determined by a Product Manager (who knows the end-user best). By playing the role of a Service Broker, the EA understands how to “stitch” together various services to deliver the outcomes as needed by the business. The EA must continue to use their skillset and experience in tackling the tough issues around security, availability, recoverability, redundancy, enhanceability, reusability etc. These issues remain constant irrespective of the toolset being used to build a solution.

  7. While I must say that the article is well-written. We must first have to understand what is Enterprise Architectures. EA an be defined as “So an enterprise architecture is a design for the arrangement and interoperation of business components (e.g., workers, policies, operations, infrastructure, information) that together make up the enterprise’s means of operation, along with principles and plans governing their evolution over time” or as the Office of Management and Budget would say “An enterprise architecture (EA) establishes the Agency-wide roadmap to achieve an AgencyÂ’s mission
    through optimal performance of its core business processes within an efficient information technology
    (IT) environment. Simply stated, enterprise architectures are “blueprints” for systematically and
    completely defining an organizationÂ’s current (baseline) or desired (target) environment. Enterprise
    architectures are essential for evolving information systems and developing new systems that optimize
    their mission value.”

  8. David Colbourn

    Respectfully I disagree. I do agree with your statement that (“control” over the design parameters of enterprise computing is starting to be highly distributed) but just in the last 22 years. Viewing the future of architecture as belonging to enterprise product managers may also be a bit narrow and may be assuming a lot of OP EX funding as enablement.

    I am not sure that making a product manager into an enterprise product manager encapsulates the architecture role at all, the role of designer yes, but the architect role not so much. In your example there is nothing to stop two different enterprise product managers from selecting different non interoperable cloud configurations, which is the role of the architect.
    Your arguments favor a tactical approach which is the day facto trend but since there is no shortage of project view of strategic needs I think it is a bit like arguing for traffic congestion. Personally I believe the mix of strategic to tactical work in the field has favored tactical at the expense of strategic or long term planning and goals.
    Additionally product managers have an inherent conflict of interest built in that precludes them from performing the architect role. The optimization of their product performance is their motivator. The architect has to balance all products and advance the use of vanilla cots when there is no clear competitive advantage, while a product manager is charged with advocating that the product does offer a competitive advantage. Someone should be working for the whole enterprise.

    Standards generation and advocacy is only a small part of architecture and can usually be off loaded to the designers to some degree although some are more important than others. Yes this is a fly in the ointment but it is a purposeful fly.
    Architecture is not one job or skill set; Network architects are rarely also the business architects who are rarely application stack or hardware or data or security architects. Yet each of these roles is tasked with supporting interoperability and maximization of resources with an enterprise or corporate responsibility.
    I do agree with your conclusion regarding the emergent behavior of intricate systems will be amazing but not amazing in a positive way based on what happened last time the industry went distributed without policy guidelines that limit the tactics for given strategies. Doing business in a way that optimizes for every project creates low interoperability and missed targeting opportunities. Corporate resources are a zero sum game and someone needs to be optimizing for a work load mix that cuts just the right corners.

  9. Jeff Putz

    I’m a little surprised at the comments that suggest pigeon-holeing various roles. That’s the opposite of what business needs, especially when you’re paying them six figures.

    That said, this piece is wrong. The dudes worth their salary were always filling multiple roles.

  10. Jimmy Isaac Ventura Salcedo

    I disagree with the view presented here. A person with an Software engineering background should not be meddling in market analysis. That is what the marketing department is for!

    It makes a good point against trying to lock down the platform but then it distorts the profession by putting marketing as part of an Architect’s responsibility.

  11. I think you are exactly right when you say, “The complexity of application design in a cloud environment is around the relationships between components, not the components themselves.” If you would like to see a more formal way of looking at this, see my web short, “The Mathematics of Cloud Optimization.” I believe that the primary job of the enterprise architect is to manage complexity. Successful businesses tend to naturally coalesce around components, and the EA needs to make sure those business-level components project onto the IT architecture. (The Web Short is at

  12. Vanessa At RJL

    I would like to add that this perspective should be likened to the five hundred pound man who is trapped in his own home and has a care taker that enables him to consume enough food to not only sustain his weight but grow to the point where the only way out is to knock out the wall. I liken it to this because uniquely surrendering to one model as the holy grail is befitting of death by consumption.

  13. Luciano Pereira Lopes

    To my understanding the term “architecture” derives from degree of complexity on distribuition of functions accordingly to favor a easy flow, no matter where the necessity originates, allowing for a proper treatment so that the control could be exerted regardless of activation or restrictions. That’s what architects have been dealing with for centuries whether hospitals, prisions or temples. Menagement is another entirely differnt trade as it involves human relations, not political interferences.
    Luciano Pereira.