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.
Had a coworker move to an EA. All i saw was the same shit pay, the same shit work, and my own workload stack up while his lessened. Yet I made less, worked twice as many hours, and got none of the recognition. EA's should be shit canned.
Maybe you didn't get any recognition because you were an easily replaceable grunt that was helping to build the system that your coworker architected? The carpenter working on a flashy new building doesn't get any credit either while he toils away at relatively low pay to build the design from the architect.
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.