How to Remaster Enterprise Architecture for a Cloud-Native World

February 27, 2017 Richard Seroter

You'll find negative stereotypes for most jobs. "Ambulance-chasing lawyer."  "Greedy banker." "Corrupt politician." One that hits close to home for me? "Ivory tower architect." You know the type. Focused on pristine diagrams and IT standards instead of real-life concerns. When I was an IT architect, I tried to buck that stereotype. But unfortunately, it's a reality within many companies and slowing down their required evolution. That doesn't have to be the case. How can enterprise architects champion the org changes needed to compete with the cloud-natives? Let's talk about it.

Look at what we ask for from enterprise architects today. I pulled these from public job postings:

  • "Defining and implementing optimal governance structures, architectural standards, and compliance processes to ensure conformance of all technology projects."

  • "Promotes the use of shared infrastructure and applications to reduce costs and improve information flows."

  • "Develop architecture models to represent system, application and data architecture designs and implementation patterns"

  • "Evaluate and participate in new technology evaluation processes (technology evaluations, proof of concepts) to support the business strategy."

  • "Establish standards around development technology stacks, including languages, containers, frameworks, libraries, and design patterns."

The common thread? Structure, efficiency, compliance. Basically, governance and inward focus. There's nothing inherently wrong with that, but something's missing. Cloud natives care about customer experience, service lifecycle, adaptability, velocity, and continuous learning. Shouldn't enterprise architects introduce those characteristics to traditional companies?

Does that mean enterprise architecture isn't useful? Of course not. Without a bigger picture view, you end up with anarchy. But we see a growing number of companies embrace agility and deprioritize the classic hands-off architect role. That could be one reason why interest in architect jobs is flat, and interest in actually building things is on the rise.

source: https://www.indeed.com/jobtrends/q-developer-q-architect.html

There's still hope. Enterprise architects stand to be one of the biggest change catalysts for their organization. But it requires a new approach. Here are ten tips, across three categories, to help EA become agents of change.

Refresh Your Patterns

In my experience, architects often start their careers as developers, security pros, or infrastructure engineers. The pace of technology changes is epic, and it's easy to fall out of date. Consider the following areas to focus on:

  • Champion new team organization patterns. As an architect, you can bring developers and operations teams together. Recognize that functional silos slow down delivery. A DevOps-type approach really works. Architects are perfectly positioned to pioneer new team structures that increase velocity and customer attentiveness.

  • Encourage new data integration patterns. If your architecture diagrams include a box for "ESB" and "ETL", it's time to start over. Integration has undergone a renaissance thanks to SaaS connectivity, event stream processing, and citizen integrators. Spend time studying these new approaches and help your company improve how they act on data.

  • Reconsider standard security patterns. Specifically, reconsider how you think about threats. More monitoring may not be the answer. Learn about new thinking that looks at going fast to stay safe.

  • Get some hands-on experience. Stop relying on vendor briefings or industry analysts for all your tech perspective. Go to conferences, download and try technology, or spin up a public cloud account. It's never been easier. You won't be credible nowadays if you stay at a 50,000 foot view.

Take Responsibility

Architects occasionally act like seagulls who swoop in to drop some ... wisdom, and disappear. It's time to take more ownership, especially after a design is put into place. Some suggestions:

  • Become a trusted advisor to tech teams, not just business execs. I get it. It's fun to hobnob with the business leaders. But, I've seen architects forget the people who have to live with architectural choices: the developers and operators. Get hands on, spend quality time with project/product teams. Don't just spend time with big enterprise projects, but also 1 or 2 efforts that incubate cool technology.

  • Enter the on-call rotation. Devs wear pagers now, why not architects? Architects should feel the joy (and pain!) of their decisions. That's a quick way to build empathy for customers inside and outside the company. You'll architect differently when you carry a pager.

  • Stop obsessing over reuse. Architects LOVE reusable components like web services, shared infrastructure, and databases. There's value there if it's the right abstraction. But it's also a way to introduce a crippling amount of coupling to shared assets that aren't designed for so many tenants. Help teams choose maintainable products, but don't force everyone to use the same components.

Adjust Your Focus

I submit that architects need to focus more time on agility and customer responsiveness. Here are some ways to do so:

  • Model customer experiences, not just technology plumbing. How do customers interact with you? Are technology systems helping you delight others? Look at the jobs to be done, and consider the COMPLETE lifecycle of interactions. You may be surprised at how many IT decisions are hostile to your customers.

  • Lighten up on rigid "standards" designed in a vacuum. Guardrails are important, and constraints can be liberating. But instead of setting standards based on abstract objectives, make sure you talk to developers and admins about what standards make sense. Also, be flexible to "exceptions" that come from teams incubating new tech.

  • Introduce technology that evolves your culture. Your culture reflects your technology. If you want to change to a customer-centric, velocity-focused company, your existing tech won't get you there. Consider self-service platforms and tools that improve collaboration and cross-team visibility.

Whether you're an architect yourself, or hiring one, rethink the role. It's not about fitting IT systems and people into clean little boxes on a diagram. It's about unleashing technology and people to create differentiated service experiences for your customers. Looking for help? Jump into our Pivotal Office Hours, or contact us to learn more.

 

About the Author

Richard Seroter

Richard Seroter is the VP of Product Marketing at Pivotal, a 12-time Microsoft MVP for cloud, an instructor for developer-centric training company Pluralsight, the lead InfoQ.com editor for cloud computing, and author of multiple books on application integration strategies. As VP of Product Marketing at Pivotal, Richard heads up product, partner, customer, and technical marketing and helps customers see how to transform the way they build software. Richard maintains a regularly updated blog (seroter.wordpress.com) on topics of architecture and solution design and can be found on Twitter as @rseroter.

Follow on Twitter More Content by Richard Seroter
Previous
Diversity and Inclusion in Everyday Work
Diversity and Inclusion in Everyday Work

Pivotal circles back on its first year to make diversity and inclusion part of our everyday work—here's how...

Next
Cloudbleed: What Pivotal Customers Need to Know

Pivotal is currently investigating whether any Pivotal products may be affected by the Cloudbleed vulnerabi...