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.
...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.
Somebody should tell "InfoWorld" the "World" part is a misnomer.
It's really just a website, not an entire world.
The "Info" part is debatable too.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
Ultimate the company makes *something* that it sells. That is the TRUE DRIVER for change. They will have to adapt as their market changes, invent new things, change processes etc.
To deliver that thing, they use stuff, computers, offices, factories, machines.
So the CIO or Architects job is to drive changes that match the business driver, and to minimize changes that don't help the true business driver. So if your staff are pissing around with the latest switch from an email server to a cloud server, or upgrading to Windows 10 because its real cool, or whatever, that is a distraction from their business. Even if you think it will make them more efficient based on some magazine you read.
Experts, by their nature, know their processes by heart. They don't need to consult the manual because they've done it so often they know the nuances of the task. If you keep changing shit under them for no reason, you are constantly destroying their expertise. They need to relearn pointless stuff that will change again a year later. So keep yourself in check.
So your job as architect is to basically sit at your desk and keep up to date with technology trends ignoring 99.9% of it that it irrelevant to your business, and only applying the 0.1% that is useful. Even then, you will likely find it useful to bunch changes together in one jump to minimize the nuisance that your stuff does to the people who make the actual money.
If its not broken, don't try to fix it, UNLESS you can anticipate a clear break in future, in which case your architects job is to, change what needs to be changed at the most efficient time in the coming period in order to minimize the damage the change makes to the business.
To sum up: You are not the driver of the business, the market for its product is. Keep your changes aligned to that market.
Any decent architecture addresses its limitations up front, particularly with regard to scalability. The fact that business units funding engineering teams tend to fund the cheapest available solution to get them to their next bonus target is another matter entirely.
The article starts out with
1. I would stay away from technology speak and jargon...
and then does that so much I couldn't read past point 3.
I first thought they meant John Milton. I do not watch TV.
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
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.
Milton was known for threatening to burn down the building and poison resort food if he didn't get his way. He followed through with the first. So are you saying that all enterprise architects are terrorists?
Say Milton and I think "Paradise Lost", or when I am really, really high, maybe a bit of lyric that goes like "for I have dined on honey dew and drunk the milk of paradise". Never seen Office. UK or US rip-off.
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.
"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."
When they talked about "Miltons" my first thought was John Milton, and thought it must be about losing and regaining architectural paradise! Shows how fucking out of touch I am with modern culture
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"?
EAs have even been called the "Miltons" (as in Milton from Office Space) of the enterprise.
People who call them that are probably jealous (better skills, higher salary).
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
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.
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.
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).
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...
A good EA can be extremely valuable. There are a lot of bad ones out there, but they do serve a purpose. Designing a good system means designing a system that can grow and adapt to needs. It doesn't mean you have to design or build a horribly inflexible system. They're not mutually exclusive.
I'm seeing the same problem that you get into with sys admins and support people vs software engineers. If you were to poll slashdot for how horrible software engineers are to tech support and maintain systems for, all the IT folks would come out of the woodwork to agree just like this story. However, there is another side to the whole thing. As a software engineer, you need admin rights on your system to do your job. It's not programmers faults that many development environments need to run server software or be admins to properly debug due to poor design of the host operating system. It's not the programmers fault that all the servers run Linux and some clown decided to install windows on their work computers; they'll need virtualization turned on in the bios. Conversely, it's extremely difficult for IT people to tech support a group of people who can install anything and make your network at risk because they got the installer from source forge or decided to login to their work PC with elevated rights like one of my coworkers do daily.
Both sides have a point. The complaints about EA are true for bad ones and not true for good ones.
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.
In the movie, Milton won. He got all the money and retired to a small island. Isn't that what we all want?
The biggest problem with IT is that it has become a religion and we argue about it like religion. Agile is the Protestantism to Waterfall's Catholicism. In all the time we talk more and more about refining our processes and invoking new technologies, we get further and further away from the business. I now work in a scrum environment. My tasks are so small and trivial I cannot possibly understand the system I'm working on. When the business is considering a new feature, they ask the developers how the system works. How messed up is that? The EA is just another symptom.
Speaking of which, has anyone heard of the new job created call a Business Architect? Take a bad analogy from IT and try to apply it to the business.
The EA should... 1. Take the long view in any discussion of IT acquisition constantly fighting the "ooh! Shiny! I want!" zombies filled with lies from vendors. 2. Create an architecture with custom views that show each customer the IT stuff they are interested and how it is related to what everyone else's IT stuff. 3. Get buy-in from everyone in writing, email, if verbal, then record it and have it ready for playback on a moment's notice especially for those people who like to ambush you in the hallway on your way to the toilet. 4. Try to get everyone to focus on the IT that supports the operations that support vision/strategic plan/whatever long term guidance documents your organization uses. This is really the same as 1. I am saying it a different way for emphasis. 5. Reduce variation wherever possible but recognize unique processes/situations/requirements that are not one size fits all. 6. Explain to anyone who will listen that you are not any of those other "architects". 7. Recognize anyone who supports your efforts,
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.
Thanks - sounds very harsh.