Are Enterprise Architects the "Miltons" of Their Organizations? 131
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.
Seen this first hand (Score:1)
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.
Re:Seen this first hand (Score:5, Interesting)
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.
Re:Seen this first hand (Score:4, Interesting)
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.
Re: Seen this first hand (Score:4, Informative)
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.
Re: (Score:3)
The catch with not being "cross-platform" is that your designated platform may still quickly go the way of the do-do even if it is associated with the brand du jour for which you cannot be fired for buying.
ActiveX is a great example of that.
A good developer has to see past the current development cycle. Never mind anyone with "architect" in his job title.
Some well made systems can last 30 years being useful and able to deflect constant attempts by new managers to ditch it for something "shiny and new".
Re: (Score:2)
I think there are various styles of enterprise architecture and architects. I've seen many that add little or no value and mainly secure an easy job for themselves.
But there are exceptions.
In the end, no company that had a significant reliance on IT systems can do without some central considerations at all.
The question is not if you do it, but how to do it right, and with the right balance.
When the architects loose feeling with reality, real problems in developing and maintaining IT systems, you have a prob
Re: (Score:2)
I see the same with Project Managers - there are exceptions of people who can actually organise a project and manage people - but the vast majority are just incompetent seat-warmers who have only 1 skill - of getting themselves into a position where they can do very little work and disguise their lack of any value whatsoever.
at least, the ones who know they are useless do that, the really dangerous ones are those who think they're important and knowledgeable.
Re: (Score:3)
"Architect" in this town means "Programmer who isn't located offshore".
Re: (Score:1)
Re: (Score:2)
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.
Amen, brother, a carpenter like that will never get proper recognition. If you really want to make it count, you gotta start your own religion.
Re: (Score:3)
It's not a problem, it's something you can solve.
Re: (Score:1)
Yes. Hire a hitman to create an opening for a new enterprise architect.
Re: (Score:2)
I have technical skills, which I work on. I don't have particularly good negotiation skills, and in complicated negotiations I tend to clam up and say "No" a lot until I've got things figured out for myself. Since my negotiation skills are adequate for most of my needs, I don't work hard on them. I'm a serious introvert and would likely have been diagnosed as autism-spectrum if they'd been diagnosing that back when I was a kid.
In other words, I don't have any natural talent for negotiation and have ot
Re: (Score:2)
Somebody negotiating better than me is not something I can realistically solve
Read this book [amazon.com]. Most HR people aren't particularly good at negotiating either, so it's not like you need to be super skilled.
It helps to know what your skills are worth on the market?
Enterprise Architects Are Devoted... (Score:1, Troll)
...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.
Re: (Score:2, Funny)
Herbert.
Herbert Herbert Herbert Herbert...
Re: (Score:1)
I am now and thus my post looking forward to their demise.
I don't know about your org.. (Score:1)
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!
Re: (Score:2)
Can't say I disagree with you.
But, someone has to keep an eye on the long term IT/Network Plans.
If we left it to Marketing, the lead time would be less than 30 days on everything.
The last big company (65k+ employees) had an EA department.
I worked supporting networked systems projects from start to production roll out, upgrades, and replacement.
Mostly HP/Sun Unix with storage (local & SAN) with high availability..
Our team kept getting bigger over t
Re: (Score:2)
As an EA, I'd say you managed them properly.
I don't have time, energy or desire to work out which technologies you should buy. I want you to be informed, apply due diligence, express a strong preference and back it up with evidence that it's not an incorrect choice.
Where I come in is making sure that you don't have EMC, Hitachi AND HP storage, that you pick one midrange server supplier, that you meet the necessary balance between cloud and on-premise servers, and that you're letting Sourcing manage the vend
Re: (Score:2)
Make sure every fucker else engages with that team to use that tool, and doesn't buy their own.
And this is why EAs are frowned upon and 'shadow' IT happens. The first team to come along evaluates candidate tools according to their needs,and are considered reasonable enough blokes. A second team that would *dare* not have the same needs as the first team are *presumed* fuckers until proven otherwise. Nevermind the first team's mission centered around managing a fleet of globally roaming Windows laptops, and the second team's mission focuses around densely packed rackmount servers in specific datace
Re: (Score:3)
So what, you want me to know in detail the needs of every team in the organisation, and the capabilities of the 1300 pieces of software we already have deployed, and the opportunities presented by the 80,000 pieces of software we could potentially deploy?
Don't be bloody stupid. I need to trust other people in the company. I need to encourage them to collaborate, find common solutions - IT or otherwise - and avoid duplication. Where people tell me they have a special requirement and they're precious and I ju
Re: (Score:2)
So what, you want me to know in detail the needs of every team in the organisation, and the capabilities of the 1300 pieces of software we already have deployed, and the opportunities presented by the 80,000 pieces of software we could potentially deploy?
The issue is not expecting you to know all of that. The problem comes in "In the meantime nobody's installing anything else if I get to hear about it", which suggests that you *don't* trust other people. Maybe you were oversimplifying for the sake of an internet forum, but the impression that someone coming in with a request to deviate is a 'fucker' suggests you have a pretty strong prejudice, and I've seen it frequently enough that folks are unreasonably held to a certain product or product line even as
Re: (Score:2)
The term 'fucker' is a throwaway catchall. Don't take it personally. It's a kinder word than 'muppet' which I'm more likely to use in the office ;)
However : Yes, I'm grotesquely over-simplifying.
I can't do my job by being a blocker. People would escalate around me, I'd get grief from my management, I'd be ineffective. That doesn't help anybody.
Broad brush, behave, follow the standards. Specific cases (and everything becomes a specific case) lets take a look and understand the right approach. Hell, the stand
Re: (Score:2)
Just want to say thank you for your clear and patient explanations of what an Enterprise Architect does. Getting informed and intelligent comments seem to be increasingly rare these days. It gives me hope there is a reason to keep reading this site.
Re: (Score:2)
Not sure I'm being all that patient or selling the role, but thanks anyway :)
Re: (Score:2)
You're welcome. And you're doing a better job than most of the EA forums I lurked on for years ;)
Re: (Score:2)
EA forums are full of people promoting the one true way. I've been doing it too long, bored with the theory these days and just focus on tangible outcomes.
Although Gartner are now pushing that theme too - outcome centric EA. Well shit Gartner, who'd have thought.
What helped me was realising that the business leaders knew 90% of the right answer already. Instead of spending months confirming the obvious I switched to focussing on helping them deliver the stuff they did know about. Means throwing 90% of EA me
Re: (Score:2)
In the meantime nobody's installing anything else if I get to hear about it.
Therein lies the problem.
If I'm picking a different product to install, it's because I've done my own research, and found that something else will make my system better, even if it's for silly reasons like "easier integration" or "doesn't require a call to a sales rep every time it breaks". Having an architect tell me I can't use it because something else has already been declared the standard just tells me that our architects are wasting our time and money.
I understand the benefits of standardizing, and of
Re: (Score:2)
As proof by analogy, consider that I'm currently fighting my way through management trying to explain why a cloud-based monitoring solution is not going to work on systems that are designed to have no network connectivity.
There's a big difference between "I need a monitoring system" "Here's the one we already have licenced, installed and supported" and "I need software that can capture system metrics so that if the server fails we can connect to the console via a serial port and run some diagnostics" "Ok, we don't have anything in that space, what would you recommend?"
Clearly you've found another route through, but that's not a failure of standardisation, that's a failure of process or the people following it.
Re: (Score:2)
In this example, the condition of 'no network connectivity' does not imply 'no network connectivity if things go wrong', it means 'no network connectivity'. So in his example, even when things are going *swimmingly*, the dictated standard of using an internet hosted monitoring infrastructure is not going to fly.
Standardisation is a term that can mean a lot or very little. If things were so simple that everyone who says 'monitoring' could be met with the same thing, the marketplace for that set of technolo
Re:I don't know about your org.. (Score:5, Insightful)
"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.
Re:I don't know about your org.. (Score:4, Insightful)
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.
Re:I don't know about your org.. (Score:4, Interesting)
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.
Re: (Score:2)
Is it cheaper to configure the tool to support your complex multinational reward structure, or to build multiple national reward systems?
Is it cheaper to configure industry standard GL and financial reporting software to meet your reporting needs, or to bespoke the lot?
I trust my development teams to build world class software that delivers discernable differentiation in the market place. For that reason I have them doing that, not rebuilding the same fucking HR, finance, sales and marketing systems that I
Re: (Score:2)
"Is it cheaper to configure the tool to support your complex multinational reward structure, or to build multiple national reward systems?" Yes it can be. Sometimes coding a process is quicker and easier than working around deficiencies in the existing system. Working with enterprise systems, I have a working feature that I coded myself out and running Months faster than it would take to change the configuration. Don't mince words, these configuration are just as complex as any programming language. They
Re: (Score:2)
Even as a software vendor we see this problem. Does it make more sense to build a solution from scratch versus trying to shoehorn their requirements into something we've already got on the shelf? Trying to do the latter can be a disaster where the end result is so customized you're not really using any part of the "off the shelf" solution anymore.
So the idea that it makes sense for a company to do it themselves is not so shocking. They could even outsource the whole thing if they don't have their own staff.
Re: (Score:2)
Not every part of a companies processes are related to their competitive advantage. So you identify the processes that are not a competitive advantage and use an out of the box process to standardize it.
Re: (Score:2)
Yes, if you do have SAP or Peoplesoft you're going to need a development staff. It's going to be a much smaller development staff than you'd need for writing all that stuff yourself. In addition, your software will conform to all sorts of laws and regulations you'd have to have in-house expertise on to write your own enterprise software. It's safer to go with the enterprise software, and businesses like safety here.
I'm not sure you understand how competitive advantages work in practice. No enterprise
Re: (Score:2)
I have yet to find a single architect who knows what he is talking about
While I have met many people using the title 'architect' as a vanity thing, or flat out misrepresenting their skills, to have found none that are competent suggests that the issue may lie with you rather than them.
Architects by definition are shitty developers that can't code if their lives depended on it
Ok, confirmed. The issue is you.
Re: (Score:2)
In mine, if the entire enterprise architecture teams were "hit by a bus" then likely no one would notice.
Jeezuz H. Christ.... Generalize much? Yes, yes. We can all tell stories of this or that [insert title here>] who was a waste of space, but a talented EA is a rare and valuable resource. I have seen far, far more damage done because of the lack of one that by a less-than-gifted one.
Evolution is key (Score:4, Interesting)
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.
Re:Evolution is key (Score:5, Insightful)
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.
Re:Evolution is key (Score:5, Insightful)
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.
Re: (Score:2)
Yes, readability is very important. Sadly, the trend I now see is that those migrating towards a senior role (or, what they believe an EA is) are unable to progress past the first couple of chapters. Had they, actually, had the proper training and mindset, they would be able to understand what the true value an EA brings to a business by having designed a system that is flexible and won't break as the business grows. Instead, we see senior individuals relegated to pasture and younger, less mature and exp
Re: (Score:2)
But, I can't find a job. I am finding that I am either overqualified or not specialized enough in the language/framework of the week or the role of architect is now being filled by organizations paying $80K instead of the $120K+ we used to command for the same "title". Like everyone else, I've got bills to pay. Yet, many hiring managers seem hard pressed to understand that I am comfortable going backwards and doing more coding for less pay. You might say you will never get in this position - I know that's what I did. Surprise.
Rewrite your resume to show that you did programming instead of (whatever). You can even change the title of your last position from "Enterprise Architect" to "Software Architect" or even "Programmer." If you want to be strict, explain that your resume doesn't list the job titles, it describes the role you were performing. And indeed it was something only a programmer can do well.
Re: (Score:2)
But I'm not talking about anything so esoteric as many-many relationships or sets vs. hierarchies.
I'm talking about the simple fact that requirements change over time.
Re: (Score:3)
You're focusing on a tiny detail. The overall point (as I read it) was that if you don't build in flexibility at the start it'll bite you later when you need to make changes. If you do build in flexibility it'll increase the up-front costs and probably the running costs too - for things you might never use.
The bummer is you don't know in advance exactly what kinds of flexibility you'll need.
Re: (Score:2)
Requirements are not a tiny detail, and over-engineering a solution when you don't know what the new requirements will be is a waste of money and time.
Re: (Score:1)
I have to partly disagree. There are certain patterns of change that are fairly common. If you are able to make a reasonable estimate of their future likelihood, you may find it easier (less net cost) to put it into the design up front.
A rough example is a system based on 12 categories of something in the domain. You know those 12 categories are likely to change in the future such that you don't hard-wire them into the design. Otherwise, you have to rework a lot of code that uses categories when they chang
Re: (Score:2)
Yes, I agree. But in the cases you describe, the flexibility and configurability are requirements. :)
Re: (Score:2)
Never said they were. Two comprehension fails in a row.
Which is what I said.
However Tablizer does have a point that you can, with experience, reasonably guess what will come up, e.g. an accounting system probably will need to handle multiple currencies at some point, aircraft fuelling systems need to handle kilos...
Re: (Score:2)
For example, hierarchies are much easier for most to grasp over set theory
If you actually think that, then I really hope that you never design a UI that normal people have to use. Your assertion is true for about 10% of the population (which has a very large overlap with people who become software developers). Most people find notions of union and intersection of categories a lot easier to understand than hierarchies.
Re: (Score:2)
If you actually think that, then I really hope that you never design a UI that normal people have to use.
why so harsh? he probably picked that up in some 'enterprise architecture 2.0' manual while looking for concepts for some flashy presentation, and it worked there, and nobody ever told him it was utter bs.
Re: (Score:1)
My experience differs. While they may understand the general concept in "toy" examples, applying it to the org's actual domain for non-trivial use is another matter.
Duh (Score:1)
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.
Re: (Score:1)
and there's no slash in www.slashdot.org
Re:Duh (Score:5, Insightful)
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/ [huhcorp.com]
Re: (Score:2)
oops.
UNLESS your name is "Google" or "Amazon"...
Sorry for the error.
Re: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:3)
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 chang
Re: (Score:2)
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.
Re: (Score:2)
I thought the 'architecture' thing was dumb too because buildings constantly require maintenance, upgrades and additions if they are to remain habitable.
Re: (Score:2)
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 r
Paradise Lost? (Score:2)
I first thought they meant John Milton. I do not watch TV.
Re: (Score:1)
Re: (Score:2)
Computer Architecture is Landscape Architecture (Score:4, Interesting)
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...
Re: (Score:2)
No, awful analogy. Landscape architects turn up, get a JCB to dig you a new pond, throw some rocks in and fuck off. Shit grows, but gardeners look after it and 200 years later it's a national park.
EAs turn up, get no funding, get an impossible set of criteria to meet, do their best to facilitate constructive change, then before anything is delivered the business changes direction and they have to start again. Repeat. Infinite loop.
It's a very different set of challenges, and needs a very different approach
Re: (Score:2)
No, awful analogy. Landscape architects turn up, get a JCB to dig you a new pond, throw some rocks in and fuck off.
One word: Accenture.
EAs turn up, get no funding, get an impossible set of criteria to meet, do their best to facilitate constructive change, then before anything is delivered the business changes direction and they have to start again.
Just because what I'm describing is not usually found, does not mean it is not the ideal model to push for.
I'm describing how it should work, the deviation from
Re: (Score:2)
Well, yeah, I'd like to have a solid baseline set of inputs, time to.implement and stability through that period.
Since we know that's not going to happen, let's avoid pretending that it is and instead focus on what can sensibly be.done.
Re: (Score:2)
Nothing can be sensibly done in an impossible environment, or nothing meaningful anyway.
That's why I want to think more about overhauling the whole concept.
Buildings should also be flexible. (Score:2)
For those of us that never bothered with a remake (Score:2)
Re: (Score:2)
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/... [wikipedia.org]
Re: (Score:2)
Re: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:2)
It can go either way (Score:4, Interesting)
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.
Re: (Score:2)
I have the title of "enterprise architect" and there's only one thing you've written that I'd disagree with:
EAs can almost be thought of academic positions.
Noooo! It's a very engaged pragmatic role. Otherwise you do get the technology religion, framework nazism or ADHD architecture anti-patterns you've capably described.
EAs need to be personally accountable for business change, or they dissociate themselves from its failures and rescind into academic ivory towers where "It's a solid plan, if only they'd implemented it properly."
No. Help them implement i
Is Enterprise Architecture Completely Broken? (Score:2)
Makes you wonder: are there any Miltons in your organization?
Sadly, for some large enterprises, you need look no further than the Enterprise Architects [forbes.com]."
Both arguments have a point (Score:2)
EA is valuable if done well, but easy to do badly. (Score:4, Insightful)
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.
Re: (Score:2)
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.
Re: (Score:2)
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 ;)
Architects: poor analogy (Score:2)
This is a poor analogy. Architects are often engaged to make changes to structures. Often more frequently than building from scratch.
I don't watch Office Space. (Score:2)
What the hell is a "Milton"?
Re: (Score:2)
Someone else who's been in a cave for two decades.
Easy Solution (Score:1)
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 mont
with my compliments (Score:2)
IT's role in the enterprise is very important. Can I be an Enterprise Architect now?
Don't dis real brick and mortar architects (Score:2)
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.
What value? (Score:2)
Re: (Score:2)
Re: (Score:2)
Have you been living in a cave for the past couple of decades? The movie Office Space came out in 1999.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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 ski
Re: (Score:2)
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.