Coté's Commonplace Book
This week, news around Microsoft’s Azure Stack drove a lot of private cloud talk around these parts. Also, I’ve been trying to figure out what “Cloud-native Enterprise Architecture” means. Links and notes below.
Also, if you’re into Software Defined Talk, we’ve created a Patreon account. One, if you just want to give us cash, hey, we’ll take it. And two, we’re trying to figure out member only content. I think we’ll try with some bonus episodes where we do extended/extra analysis of white papers, surveys, and other tech industries studies and things. Go check it out and it’d be mighty fine if you helped us out.
Podcasts
A recorded talk from this week
|
Cloud-native Enterprise Architecture?
I get asked a lot about “enterprise architecture” in a cloud-native/DevOps world. The stock answers are pretty terrible: “HAH-HAH-HAH!”
I’ve been looking at some old sources and talking with folks who work in large organizations on this topic to see what’s happening. Also, I’m putting together a talk on the topic (you know, once I figure it out).
My main theory is that enterprise architects only matter for large scale. “Cloud-native” (and DevOps) changes two things: faster release cycles and automating most all of the infrastructure. I’m not sure these “cancel” out the benefits of enterprise architects, so/but the question is: what does this role need to change about what it does to keep being helpful? Can 100’s of cloud-native teams just operate on their own with no EA support? Does some other team take on the EA function (with the help of automating everything)?
Is it just that the traditional tools and timelines of EAs are now crap, or that the whole function is now crap?
So…settling on a traditional definition of enterprise architecture (based on Enterprise Architecture as Strategy, 2006):
- First, you diagnose and identify the type of business you have: a bunch of independently operating business units, or more unified.
- Then, you figure out what IT and IT process can be shared among them, with an eye towards optimizing costs and enabling growth/innovation. Not all organizations care about both.
- You map the “operating model” of the business to rectangles in IT (see Delta’s model in the book for a pretty good one).
- This divides up your teams, projects, etc. and allows you to find common tech/platforms/etc. to share, if you care about that.
- Managing scaling and scaled IT - the constant thing you’re managing is understanding the operating model (how the business operates and how IT can make it more better), and deciding what the standardize and centralize.
- There are bonus features like exploring new technologies, informing the process to be used on the team.
- There are “functional” things like ensuring compliance, security, etc. - at the very least, governing that someone is caring about it
- Other things, and governance.
Links
