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.
...to the development of the "Star Trek" economy. Anybody whose livelihood depends on the fleecing of others beware. The "Merit" economy is coming. You get what you give, not what you take.
Time is what keeps everything from happening all at once.
In mine, if the entire enterprise architecture teams were "hit by a bus" then likely no one would notice. For years. Well. Except perhaps minus some insane decisions about removing useful free desktop software. Other than that, no, their non-existence would not be highly noticed.
Less curry theft perhaps.
Less draw on payroll.
Less noise on two floors.
Less woo hoo yee har ridem cowboy headshot! headshot!
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 there's no slash in www.slashdot.org
Table-ized A.I.
I first thought they meant John Milton. I do not watch TV.
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
oops.
UNLESS your name is "Google" or "Amazon"...
Sorry for the error.
Architecture is not just about rigidity. That said, it's a legislated profession so maybe shouldn't be used to describe someone without a stamp.
- In Soviet Korea, only old people loose all their bases to Natalie Portman's petrified hot grits overlords.
For those of us who have not seen the US remake of The Office what defines a "Milton"?
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.
Well it's posted by StewBeans - the guy who brought us the one about "getting ubered".
He's basically just a shill for enterprisersproject.com
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
"Remember Milton, the red stapler guy from the movie Office Space? Useless to his company, he had been laid off years before, but due to an unexplained glitch, he was never informed and kept getting paid. So there’s Milton, showing up for work day after day, clueless about why he has nothing useful to do.
Makes you wonder: are there any Miltons in your organization?
Sadly, for some large enterprises, you need look no further than the Enterprise Architects."
For those of us who have not seen the US remake of The Office what defines a "Milton"?
The reference is to Office Space, not The Office.
Seriously, you missed one of the most important films of the 90s? The film that revealed the truth about TPS reports!
But seriously seriously, check out Office Space. If you enjoyed the original The Office - and are of an IT bent - it will probably tickle you.
https://en.wikipedia.org/wiki/...
Plenty of EA's are totally clueless, have no idea what they're doing, but are great at feeding buzzwords with an extra helping of BS to the CIO. However the EA can be a valuable and worthwhile position, but you need a good CEO to select a good CIO who selects a good EA...pretty rare occurrence in my experience
Fine, you like it a lot, I get that, but what is a "Milton"?
The analogy still holds. Somebody has to justify the ways of god to men, just that Milton couldn't do it in UML.
Milton Waddams, a meek, fixated collator who constantly mumbles to himself. Milton had actually been laid off years earlier, though he was never informed and, due to a payroll computer glitch, continues to receive regular paychecks
Mod parent up into the sky!!
This huhcorp site is one of the funniest I've seen in recent times.
Just for the record, and entirely coincidentally: this morning I was called by a recruiter, asking if I'm interested in being interviewed for a position of "Senior IT and Enterprise Architect". Tomorrow. I thought "yeah, why not". So I said I'll go. I'm wondering what kind of birdshit-buzzwords are going to fall on my head tomorrow. Can't wait.
Religous speak to God. Insane are spoken to by God. When all shut up, one can finally hear Shostakovich in peace
And that article is one of the worst I've seen.
I would say that I see our primary role is to proactively drive positive change while developing the right responses to capitalize on disruption in our industry.
Boy, he wasn't kidding about point #1, was he? ("[...] stay away from technology speak and jargon and talk the true potential of an enterprise architecture (EA) program to deliver on real business results.").
I am sure he's a very capable guy, but as an EA, his role is not to "drive positive change"; it's to enable and guide it, or at least to not get in the way.
In other words, you want to play beta-tester with the company's business. For technology that you do NOT control.
In the places I've worked, EA was mostly about cost, quality and compliance through guidelines and standardisation, not about innovation and change.Keeping innovation out of EA was a conscious decision (which isn't to say that they don't often work together closely), for the reason you stated.
If construction was anything like programming, an incorrectly fitted lock would bring down the entire building...
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.
as an EA, his role is not to "drive positive change"; it's to enable and guide it, or at least to not get in the way
Tricky one. Often an EA has to drive change, securing budgets, management backing, ground level support and the exec level sponsorship needed to overcome the one obnoxious idiot trying to protect their precious empire.
In an ideal world, yeah, EAs help people understand what's going on and where, provide insight and guidance, join up teams and initiatives and act as facilitators. In reality I find it's often essential to get hands-on and apply some heft to key projects.
cost, quality and compliance through guidelines and standardisation, not about innovation and change
Again, this is a bloody tricky balance. You want cost control, you must have compliance (or the regulator will shut you down), standardisation is a great way of improving efficiency and assuring outcomes (for customers, regulators and shareholders). You also need the innovation and disruptive technologies, so you need an environment that encourages and supports them.
That means EA need to be part of that process. I can't demand that you do X if it stops you exploring something that could change the industry. I want you investigating Y, and helping me understand its maturity, its possibilities and when it might be ready for adoption by the rest of the company. So innovation is just another business activity that needs facilitation, funding and a level of control.
I'd agree that doesn't meant that I should be doing the investigation and exploration myself. I may realise that it's needed, but lets get a team that understand that domain in depth to do the hands-on work. They'll do it better, they'll build up the skills we may need, and it frees up my time to sit with an MD and convince them that they aren't a special snowflake and they really don't need their own AWS master key.
let's face it, software is more than half of the problem space
No. It's all people and politics; technology's the easy bit.
Although even ignoring the people and politics, it's all business process first, data second, software third. Infrastructure really does disappear a long way behind.
I'm saying that as a software person. The software happens to be the easiest route to understanding process and data for anybody that isn't a process or data expert.
Just as you don't write software without requirements, you don't design enterprises without understanding the enterprise requirements. Start with the business basics: Who, what, where, why, when. Only then worry about how, and even then start with the non-IT elements of how.
If its not broken, don't try to fix it
While I agree with most of your points, could you please tell me which company isn't already inherently broken? Just that I've never seen one.
Business drivers? Reduce cost, improve efficiency, eliminate errors, comply with local legislations, sell more, divest non-core businesses, acquire new businesses and build new products.
Changing the existing shit is necessary just to meet the immediate business needs, let alone the future ones.
Yeah. EAs need to be business people,and use that set of jargon.
At the same time to retain any credibility with the technical teams, they need to be technical people, and use that set of jargon.
It's why the job is fun. You're bridging two very different worlds and trying to help them find common ground and deliver the same outcomes.
I thought the 'architecture' thing was dumb too because buildings constantly require maintenance, upgrades and additions if they are to remain habitable.
love is just extroverted narcissism
I'd like to challenge 'better skills'. Different skills.
Going from software and solution architecture to enterprise architecture, my hands-on development and software engineering skills have atrophied and it'd take me months to get anywhere near competent again.
My software and solution architecture skills are still there, but primarily at a high level. I can't dive into the detail quickly and without research.
What I can now do is the politics, stakeholder management, the communication and the other soft skills needed to get people to agree on the right solution to a business problem. I didn't need those skills as much before, I do need them now.
Salary wise, you may be right. It's because instead of solving all the problems for a project, or a programme, or a change initiative, you're trying to solve them for a country, a continent or the entire company. Same problem solving techniques, different scale, higher stakes. It's still fun though :)
This is a poor analogy. Architects are often engaged to make changes to structures. Often more frequently than building from scratch.
Don't worry about it, it's completely irrelevant in the context and the way it's being used anyway.
(i.e. Knowing who this Milton was wouldn't help anyway).
Not sure if that's true. The implication (at least as far as I read it) is that enterprise architects are mumblers with no purpose still on the payroll. A stretch maybe.
What the hell is a "Milton"?
- Zav - Imagine a Beowulf cluster of insensitive clods...
1) Disappear for months at a time talking high concepts
2) Make vary large, very colourful, completely incomprehensible pictures that get pinned up on walls that nobody looks at
3) Never update the pictures to reflect reality
4) Only show up when there is free food on the table
5) When asked a serious question requiring a solution, go away and come back with a completely unworkable answer four months after the project is due, if ever
With the unpaid art-school intern option, an organization could save high six, low seven figures a year!
Fear, Uncertainty and Doubt = [citation required]
IT's role in the enterprise is very important. Can I be an Enterprise Architect now?
Hey Fross, just wanted to reply that I've also been doing this for over 10 years and you hit the nail right on the head. I really couldn't add more to your post and would mod it up if I had any points to spend. Perfectly stated.
I am not interested in articles about life extension advancements.
Thanks lazarus, always good to have some confirmation! I think it's a fascinating area to work in, though I do encounter a lot of people doing it poorly, and even more people who misunderstand it, possibly as a result of the former.
And damn thought my 5 digit id was going to be a blast from the past until you literally rose from the dead ;)
When you get into engineering it's amazing how buildings, particularly large towers are dynamic moving machines.
There are giant weights, cables and counter weights and if they go wrong the building will literally start shaking. Buildings aren't as still as you might think.
If you didn't know buildings are very dynamic, thank an architect.
I have worked on some fairly massive systems and not once I have I met an EA who brought value to the endeavour. Almost without exception anyone who called themselves an EA had a single tool in their toolchest and was damned determined to make sure that only their tool was chosen. Often the EA either directly worked for the company that made the tool or they had certifications for that tool up the ying yang. The result of having a pure EA do a huge project was failure. I never saw any other outcome. It either was killed after it wasn't finished, or it was killed after it was deployed because it didn't work. Usually there was some huge hole that simply couldn't be filled. A huge pile of systems would be ordered from some company at way too much cost, and then when the CFO was handed the highly propriatary software licence purchase order to sign he would lose his mind at the cost screaming, "This software is double the budget for this entire system. Didn't you used to work for this company?"
Where I have met people who successfully Architected Enterprise systems. In this case the person was much more of a project manager who worked with many people who brought many different experiences to the table. The key difference between the usually monolithic systems that EAs tend to design is that a group system tends to be smaller, flexible, and far more nuanced. Things like the mobile units will use a funky battery technology because many of them will be used in -20 weather. Something that a typical EA would miss if it weren't handed to him on a sliver specsheet platter.
To me it is like when you go to a growing company and one of the founders now has the title "Evangelist" usually they were the tool with the business degree who found 2 investors and has since proven themselves to be useless. Their only skill is using BS business lingo to impress unsophisticated investors. People who call themselves Enterprise Architects tend to be crap project managers who use BS technical lingo to impress technically unsophisticated executives.
Have you been living in a cave for the past couple of decades? The movie Office Space came out in 1999.
In the movie, Milton won. He got all the money and retired to a small island. Isn't that what we all want?
Yep, it was great for Milton, not so much for the rest of the company which burned to the ground. That's basically the point: a useless EA is hurting rather than helping the company as a whole, while drawing a large paycheck for it.
Thanks - sounds very harsh.