Slashdot Mirror
Are Enterprise Architects the "Miltons" of Their Organizations?
StewBeans writes: InfoWorld recently pointed out that the "architect" part of enterprise architect is a misnomer, because what they are building can't be a static, unmoving structure or it will fail. Businesses need to remain fluid and flexible as technology and consumer behaviors evolve, so modern enterprise architects must "develop frameworks with constant change as a first principle." The business value of these frameworks, however, is often called into question, and EAs have even been called the "Miltons" (as in Milton from Office Space) of the enterprise. If the field of enterprise architecture is changing to focus more on digital transformation, how does that compete with or compliment IT's role in the enterprise, which is also focused on digital transformation? The enterprise architect of BJ's Wholesale breaks down his responsibilities and addresses some myths about the EA role in this article.
There's a tricky trade-off at play. To make a system flexible, you generally have to make it more abstract: more layers of indirection, more "switches and dials", and more many-to-many relationships.
But abstraction confuses many of the maintenance staff (typically power users and lessor tech admins). For example, hierarchies are much easier for most to grasp over set theory, but set theory is ultimately more flexible. You can potentially hide sets behind a hierarchy if not using sets, but it's hard to hide the set-oriented infrastructure entirely, including the manuals (doc). Plus, the hiding costs more to implement, making the product more expensive, especially if it has many feature-hide config settings. That's a lot of config combo's for the vendor to test well.
An architecture that does what it needs to and only what it needs to at a given time is usually easier for staff to absorb. However, it also limits future flexibility. I've yet to see a magic escape from this trade-off pair.
Table-ized A.I.
And that article is one of the worst I've seen.
If that even made sense ... is there any "management" or CxO role in a company where the exact same could NOT be said?
I've worked for hazardous waste disposal companies, insurance companies and manufacturing companies. The CRITICAL parts are always 100% "nuance".
Otherwise you're operating the same as someone else and they're probably doing it for less than you charge. And taking all your clients.
In other words, you want to play beta-tester with the company's business. For technology that you do NOT control.
I'm reminded of some old advice for CxO's. Claim something is a problem and then change it. No one ever filled out their resume with "maintained the status quo".
What "rapid change"? If your name is "Google" or "Amazon" then you're probably doing the same thing in the same way in the same time you've been doing it for 10 years.
I'm more reminded of this:
http://www.huhcorp.com/
For long-term survival of a system, readability > flexibility.
You can make the most flexible system in the world, but if people don't understand it, they aren't going to see where you added the points of flexibility.
"First they came for the slanderers and i said nothing."
"Enterprise" software is a scam.
It became popular after the Dot Com bust. Because organizations decided to Can most of their IT Staff. Meaning much of it custom software infrastructure cannot be maintained. Business being like most businesses suffer from an inferiority complex that somehow they are not running as well as the rest of the industry, not really realizing the rest of the industry has similar issues. So they drop their custom stuff, fire their programmers and go with "Enterprise" software, that promises "Best Practices" expecting the vender to do actual research in best practices. But that only means it is what they programmed the system to do by default.
Now here is where it gets sneaky. There isn't any real "Best Practices" because every organization is different. You may be more expensive but want a better customer experience, you may be cheaper and avoid all the useless people talk. Every organization is different and has different needs. So these "Enterprise" Architects are often brought in, each one costing twice of your developer who you canned and in numbers greater or equal to the amount of people you had fired. To customize the software to handle the difference. (AKA Re-programming it) now you have your more expensive semi-custom built product, that doesn't run nearly as well. with a team of expensive consultants you dare not to let them get reassigned because your infrastructure is now dependent on it
Just because you didn't want to keep your development staff, you have hired a more expensive and less effective development staff.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
Disclaimer: I've worked as an EA for about 10 years, on top of another 10 years of solutions architecture and applications development. I've worked for a bunch of private and public organisations.
It's so easy to do EA badly. If you treat it like a lead or senior architect setting the technology strategy, then you're missing most of the benefits (and this should be more the CTO's domain anyway). If you do ivory tower strategy that nobody ever reads, because it's full of stuff nobody can relate to, then that's pointless and you're unable to communicate, which is the primary purpose of an architect. If you have a small outfit where those setting direction communicate well with those designing the business and technology, then you don't really need an EA.
An EA is an architect for the _business_, not (only) for the technology. The reason a lot of people get into it from technology is it shares a lot of the rigour and approach of architecture, however it is important to note it is NOT primarily a technical role, nor should it be.
A successful EA will understand the business strategy, i.e. where the company needs to be in X years, and understand the existing landscape of roles, skills, processes, technology and so forth. Their primary purpose is to define the change the business needs to go through, in each of those areas, in order to fulfil the business strategy.
A C-level execs set the strategy. The EA transforms that strategy into changes that need to occur within each level of the business, to make their vision possible. The individual specialist areas (from HR to tech to whatever) work with the EAs to determine how to make those changes happen in that timeframe.
Done well it's an incredibly powerful tool and is the mechanism that connects the "controls" to the "engine". Done poorly it can fail for any of the reasons above, from people who see it as having a purely technical remit to those who sit around in Archimate all day making models nobody will ever use.
You and I have very different interpretations of the term Enterprise Architect.
In my world, they don't do any development. Then again, very few organisations develop 'enterprise' software. Most of us buy it in, from Oracle or SAP or Salesforce.
Is it great software? Not really. Is it cheap? No. Is it better and cheaper than trying to develop our own CRM system? Actually, yes.