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.
The evolution of systems is far more important than their initial design.
I challenge anyone to show me a system that didn't change during even a six month development cycle, never mind over the course of a decade.
I do not fail; I succeed at finding out what does not work.
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/
There's another role that has architecture in the title - Landscape Architect.
That is a much closer match to what is needed from a software architect. The landscape architect must think ahead to the future, at how everything that has been planted will grow, and through growth interact. The landscape architect must provide for constant nourishment and maintenance of irrigation and food and plant diagnosis and repair...
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I work for a professional services company. I have the title of "systems architect" which is just a fancy way of saying I have enough end-to-end knowledge to glue together software, hardware, network, storage, etc. to build a working product. I'm definitely not an "enterprise architect" which is another thing completely. EAs can almost be thought of academic positions. These are the guys who report directly to the CIO and basically keep up with all the goings-on in the field. Neither I, nor the EA, should have the title "architect" -- that implies designing a stable structure built to last hundreds of years. Nothing in IT Is stable or built to last.
When they're well trained, highly experienced, and provide relevant feedback, the EA position is a positive thing. However, I've seen it devolve into something less than positive. How many here work for large companies and see one or more of the following from the EA role?
- Technology choice as religion: System X or Cloud Provider Y or Vendor Z is the EA's favorite, so therefore it will be force-fit into any situation.
- "Gartner Rubber Stamp": Those guys at Gartner throw their chicken bones every year and come up with their Magic Quadrants. If Gartner or Forrester has not endorsed a technology, this type of EA will never let it surface anywhere in the organization. The big problem I have with this is that when I've seen it happen, the EA in question has no skills of their own and is simply falling back on these research firms to get their ideas.
- Professional conference-goer and vendor schmoozer: Yes, you do need to do some of this as an EA. However, I've seen this taken to an extreme. These are the guys who are never actually in the office; they're always on the road at industry conventions and playing golf with the consulting firms who will be offshoring IT next year or selling a billion-dollar ERP package whose implementation will fail. All I'm saying is that the EA role is ripe for abuse by individuals who are so inclined...I've seen a large company's "Labs" division of their IT department burn through tons and tons of money and produce nothing of value whatsoever, while "regular IT" went for years with inadequate training.
- Framework/process Nazi: What large-company IT denizen hasn't heard of ITIL, TOGAF, CMMI, ISO-whatever, horribly butchered Agile Waterfall dev processes, and other "enterprisey" stuff? Chances are that a lot of this is coming from the EA, advised by Reassuringly Expensive Consulting LLC. Don't get me wrong, process is good and necessary, but process taken to an extreme is horrible.
- ADHD Architecture: Companies shouldn't stagnate, but they also shouldn't be pivoting towards whatever brand new, unproven, untested technology comes out every 2 months. This is the danger of the position basically being academic -- vendors are salivating at the chance to sell new shiny stuff all the time, and I in engineering have been the victim having to implement what an EA saw in a sales demo. "What do you mean it won't work in our environment? The nice sales guy who paid for my strip club visit in Vegas assured me everything would be fine! Oh, I guess we should just hire their professional services team if you aren't up to the task..."
An actual experienced, seasoned enterprise architect can help keep the ship from sinking even when new technology keeps shooting holes in the hull, as long as there's a CIO-level commitment to enforce at least some key choices made by the EA. When that EA is incompetent, or a tool of the consulting companies, or just a drain on resources, that's where the complaints surface.
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.
If I had modpoints I'd mot your post '+1 Funny'. I love software architects. I once witnessed as one of these people was turned loose on a company I was working for. When they introduced him they listed his accomplishments, chief among whom was the design of a customer relationship management and provisioning web-app. The thing was extensively built on ActiveX plugins which meant that it was only usable on Windows and on Windows it only worked properly in Internet Explorer. At the introductory meeting after they finished heaping laurels upon their new software architect and it was time for questions, I was the only one to raise my hand. Being really curious about his architectural expert opinion I asked the guy what the point had been of developing a web-app that was only really usable on one browser on one operating system, why not just develop a native GUI program? I didn't really want to know I mostly just wanted to seem him weasel himself out of the question. They guy changed colours briefly, clearly discomforted by the question, and then explained: "Due to special circumstances at the time we made the conscious decision to... blah blah blah ... and thus it made good business sense at the time." I will never forget the voice of words "conscious decision". This translates into every day english as: "Well we drank some Microsoft cool aid and then ... blah blah blah ... and when we sobered up we were stuck with a giant polished turd.". Of course the company bought this pile of crap CRM system for a very significant sum of money and then retired it (along with the architect) a there or four years later.
"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.
Portability or cross-platform use is only one reason you may want to build something as a web app. Remote access, avoiding cost and complexity of distribution and installation, faster update cycles, and developer pool skills may also need to be considered.
All those configurations to get it working for your organization is just as complex as it would be to have a development staff. Better and Cheaper than developing your own CRM software??? I don't think so. Making the software may have a higher upfront cost, but maintenance, and efficiency gains will win overall.
Most organization buy this CRM software and only use a small fraction of the features, where all they want is a few forms to enter into a database.
With enterprise software, you either convert your organization to do it the way everyone else is working and lose your competitive advantage. Or pay a lot of money to highly configure the tool to meet your needs.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.