Your pedestal is showing
I just couldn’t pass this one up when it was mentioned in a comment to an earlier post. Proclaimed “enterprise architect” Robert McIlree is convinced that it’s enterprise architect versus the world. Really? The whole damned world? Or just a few people? Exaggeration is always a fun hobby.
The underlying theme behind the anti-EA, and moreover, the “Web 2.0-Saves-Humanity-As-We-Know-It” crusade is this: you, the user, can have it better, cheaper, and faster if you [ fill-in-the-programming language-or-kewl-technology blank here].
Actually, my theme is you can have it better, cheaper and fast enough if you just stop obsessing over what analysts and enterprisey architects tell you, and focus on your real core problem. The 80/20 rule still applies, and my experience is that if you are willing to settle for about 78.6503% of a solution, you can get it for about 5.324% complexity in many situations1. Instead, focusing on real solutions to real problems. Even in an enormous organization—and I’ve done solutions for entire government agencies which dwarf most corporate organizations—the problem domain is much smaller than people think it is.
As a result, when we raise numerous issues along those lines, we are universally branded by those in the diametric situation as cynics, ‘Astronauts,’ or just, “not getting it.” What these pundits generally don’t realize is, yes, we do get it, and while it’s unfortunate that you don’t like our answers, let’s look at reality one more time, shall we?
No, getting it involves doing it: getting it done. If you deliver an “enterprise solution” in 2 years, and I deliver what you degrade as a “non-enterprise solution” next week, whose solution do you think earns more money for the organization? Who do you think abates the costs faster? Most importantly, who do you think learns where the mistakes are and the real requirements exist. All those formal documents everyone obsesses over are nothing more than political fodder to feed the self-important people who obsess over agreement on things for which there is no known answer. Angels on the head of a pin, as it were.
One of the issues that drives these perception problems is that of scope. A typical enterprise architect’s scope is much more broad then that of a development team or end-user organization
And many, many problems are much smaller than that. It is correct that there are some problems that transcend departments, organizations and even corporate boundaries. They are not as common as many people would like to believe, and are often solved through the loose-coupling of many systems rather than the “top-down” dictatorial architecture often chosen.
A quick story is appropriate here. Many years ago, I was working with the Navy on a project to track maintenance schedules on fighter plane engines. Not a wide-reaching piece, but something with a clear “mission critical” nature. Screw it up and people die. Doesn’t get more mission critical than that. We were given a huge ERD of the DoD-standard database schema. It contained approximately 5,000 tables that were designed to encompass all known possibilities.
It contained nothing useful for what we were attempting to accomplish. Instead, we designed our own system, in an object-database, built around the actual workflow and requirements of the end customer. It was delivered in weeks, and was in operation for years—and may still be, as I’ve moved on. Should we have appealed to the “architect” to modify their architecture when it became obvious that they had massive blind spots?
Not all problems are knowable. Until you accept this perspective, you will continually pursue the perfect to the deficit of the good. I have watched hundreds of projects implode with the obsession over “scaling” and other enterprisey distractions when often they were irrelevant to the task at hand. Something today that works will always be better than a gold-plated Cadillac tomorrow.
We work in environments where IT budgets are in the tens of millions, and in a number of cases, hundreds of millions of dollars.
This is laughable. Huge budgets are usually indicative of run-away architecture and absurd turf-wars and protectionism, not actual success. Most IT budgets I’ve been around could be shaved 30-70% by the judicious use of the word “no,” and the refusal to accept stock answers from astronauts and certification-wielding automatons.
For example, I watched a large government agency—who asked me to do an analysis of mail requirements for an organization of several hundred thousand users—choose the absolute worst option because it was the “industry standard.” It cost 14x more than the lowest cost in simple capital, and had a on-going support run-rate that was approximately 5-6x anything else. The defense was that it was what the “industry” had chosen. The reality is, it was chosen because budgets equal power, and people equal promotions.
The masses are stupid and blind, and that is a poor rational if you want to excel. It’s a grand idea if you want to be mediocre.So…the real problem we’re solving for, as JT noted, isn’t necessarily better, faster, cheaper. In the large corporate and governmental areas, I’d argue that the real aggregate problems we’re solving for are, as examples: cost-effective front and back-end, compliant, auditable, available (pick your nines), extendable/maintainable, interoperable, and secure.
Finally, someone notes that better, faster and cheaper doesn’t matter to them. The aggregate problems aren’t that hard. People are imagining huge dragons to slay because it makes them feel important and more powerful. Those dragons are rare. There are hard problems in the computer world, but connecting some systems together isn’t once of them. This is the intellectual equivalent of penis comparisons at the gym. Amusing, but not terribly productive.
Unfortunately for people like us, here is where it gets worse: our constituencies and stakeholders are routinely pitched by vendors and pundits that they can have it all – today.
And you tell them they can have it in 3 years for another $20M, and you wonder why people are beginning to doubt your sanity, validity and talent? Time is money. Sometimes time is all that matters. Opportunity in many businesses is constrained by time as much as any other resource, but this is a fact many people forget. The window to control a market or exploit an opening is often razor thing, and that window will never be exploitable so long as you obsess over building systems for problems that don’t exist yet.
We must do a better job of selling our scope and vision to our constituencies – and not in the fashion of vendors and pundits, but as key empathetic players in our organizations.
No, you must do a better job of delivering results. Scope, vision, synergy: it’s all buzzword bingo meant to make something relatively simple sound complicated. If I can sketch the design of a global IP backbone on a cocktail napkin, and have it work, you can design an ERP system that doesn’t cost $50M to deploy. But then, you’d have to want that, wouldn’t you?
The world is not changing, and the “tools of today” are rarely anything but a regurgitation of something seen before. Ruby isn’t anything new. It just happens to have garnered people’s imagination. Smalltalk was better, so was Lisp—it’s all a matter of the definition of better for your situation. Python has played similar roles for other people. My tool-belt is ever-expanding with tools that might bet he right one for the job right now.
People obsess over the choice of tools, but the true talent, and the true skill, is the understanding of business problems that are trying to be solved, including the window available. If my tool—whatever it is—can help me focus and be more collaborative with the people whose problems I’m trying to solve, then it’s a better tool.
Never forget that IT is a drain on company resources. It doesn’t “produce profit” in and of itself. It might assist other people in making money, but at the end of the day it’s just the movement of data. Until that touches a customer, you don’t have a business. IT is subservient to the needs of a corporate and must always remain that way.
1 This is sarcasm. I’m pulling these numbers out of my orifice just like Gartner pulls it’s “Magic Quadrant” out of a bowl of mushrooms that have been sitting around the office too long.
This entry was posted at 9:46 pm on 13 April 2006 and is filed under Technology. You can follow any responses to this entry through the post-specific RSS 2.0 feed.
Well put:
Not all problems are knowable. Until you accept this perspective, you will continually pursue the perfect to the deficit of the good.
One of the best blog entries I’ve seen in a long, long time. I couldn’t have said any of it better—thank you.
Lloyd’s quote is the one I was going to quote as well.
“Smalltalk was better, so was Lisp”
Smalltalk and Lisp aren’t dead, though they’re rumored to smell funny. I don’t know about deployment within “enterprises”, but I can think of several startups using one or the other.
Using languages like Smalltalk and Lisp is a great way to attract highly skilled programmers. It’s incompatible with the way large organizations seem to run projects, but highly compatible with getting stuff done quickly.
I know they’re not dead, but they have missed their window of opportunity. I’m reasonably proficient in both Smalltalk and Lisp (Lisp was my first language after assembler, and Smalltalk my introduction to OOP on one of the old Xerox Dandelions). Ruby stands the chance of illuminating some of the Smalltalk world, I hope.
My general guideline as a hiring manager is that if you don’t have at least one or two “non mainstream” languages on your resume and have reasonable proficiency with them, then I’m not interested. A resume of C, C++, Java, VB, etc. demonstrates a distinct lack of diversity and more likely a lack of curiosity.
[...] Now, admittedly, I don’t know anything about Enterprise Architecture, since over the last nine years I’ve been the only architect, one of two or (luxury) one of three architects for the entire company. I’ve only had to integrate products and services with F500 architectures, I’ve never had to own one. Correspondingly this “fisking” of the previous artitle resonated with me. But after further reflection, I think it is also unfair to Mr. McIlree is working for a large company. People who work for large companies typically do not care about the company. They care about having and keeping a job. For many people, their employer is nothing more than an endless salad bar – whose function in life is to provide the employee with a salary. (That, typically, is one of the key differences between working for large and small companies) In that kind of environment, large budgets are a symptom of sponsors who care about their own projects. Let’s say we have Edna, who has money for a project that will improve her department. Because of architectural constraints, it will cost her $1MM (1 million dollars). Now, you’re the architect, and you know that with a $2MM extra investment, you could do a radical overhaul of the company’s architecture and make it so the next project for Edna would only cost $100,000 instead of $1MM. But Edna is not going to authorize $3MM to pay for a $1MM project, unless she’s astonishingly perceptive or swimming in excess budget. It’s not particularly fair to her to expect her to do so.  So you have to try to go to all of the department heads to convince them that $2MM divided up by 10 departments is a pittance in exchange for a cheaper/better/faster enterprise. [...]
Some really mature and compelling thoughts here.
I value people that can grab onto semantics and generate good dialogue.
Question: If the answer to architecture is breaking a complex business requirement into the simple functionality that brings the most value to the business…help me understand (1) what are some good approaches to negotiating this with the business customer (2) what happens 3 years later when multiple internal customer have built out redundant capabilities and highly customized automation that may not scale when they realize they need 4x more then originally requested?
Negotiating with business people is often difficult. My experience is that it is made doubly so by past advisors who taut the complexity that is innate in their solutions. Instead of shoeing them away like the vampires of productivity that they are, they are embraced. Unteaching this behavior is the single hardest thing. Accepting that you will fail with some customers is also important.
The hardest thing I ever learned is when I don’t want someone’s money.
[...] Chris Petrilli has a good rant against Robert Mcllree’s lament that enterprise architects are fighting a battle against, well, everyone. In response to Robert’s argument that serious software involves more time and money than “agile” folks care to admit, Chris says: If you deliver an “enterprise solutionâ€? in 2 years, and I deliver what you degrade as a “non-enterprise solutionâ€? next week, whose solution do you think earns more money for the organization? Who do you think abates the costs faster? Most importantly, who do you think learns where the mistakes are and the real requirements exist. [...]
I’m not sure there’s really a conflict between enterprise architects and others. At our company there are two different views of how software development projects should be done, and they’re both right. I wonder if it’s the same discussion in another context.
One view, coming from the IT area, is that the ideal model for IT is SOA, providing what we call an “enterprise service bus” hosting Web Services that can be called from any client application that needs them. The model makes sense in our environment because we have many mission-critical legacy applications that don’t lend themselves to integration with contemporary development tools. The service bus also provides the “ilities” for the back-end environment, so that business-facing apps need not be as concerned with issues of scalability, performance, and security as they otherwise would. The idea is that (ideally) most business apps could be build by orchestrating service calls and providing a nice UI, with relatively little custom logic needed. All this would be funded from the base IT budget and would be cost-justified on the basis of long-term savings in operating costs – and that’s the key to the disagreement.
The business side of the house is looking for quick time-to-market of small, vertical apps to help them meet short-term market opportunities. These projects are funded directly by business units and cost-justified on immediate impact to the bottom line. They don’t see how it benefits them to contribute to the cost of building the enterprise service bus.
We can deploy an agile development team to a business unit to create a solution quickly. We could do the same if that team could orchestrate back-end services, too. But the challenge is to get the business people on board with the long-term cost savings of the SOA model.
So both camps are really seeking the same thing – a reliable way to deliver business value.
[...] Now that RoR provided the valve to let the steam out of the Java web application pot we are seeing similar phenomena in the Java Enterprise pot. [...]
Well said, couldn’t have put it better myself. Infact the next time someone touts architecture nonsense to me I’ll point them here.
[...] Eine der interessanteren Diskussionen — in bester Blogmanier simultan und verteilt geführt — entwickelte sich rund um die Frage, ob man für die Lösung von “Enterprise”-Problemen unbedingt eine Technologie benötigt, die das Wort auch im Namen führt. Nicht ganz zu unrecht argumentieren die Verfechter des “lesscode”-Ansatzes, dass weniger oft mehr ist. Ausgelöst durch James McGovern, der Ruby und Ruby on Rails (RoR) sowie die dazugehörige Bewegung um den Chefentwickler David Heinemeier Hansson als ungerechtfertigten Hype und für den Unternehmenseinsatz völlig ungeeignet geißelt, hat sich neben diversen lesenswerten Beiträgen zum Beispiel von James McIlree oder Chris Petrilli auch gleich ein eigenes, abfällig gemeintes Wort für den von Kanonen-auf-Spatzen-Ansatz etabliert: “Enterprisey”, mittlerweile sogar mit eigenem Wikipedia-Eintrag. Unbedingt einen Blick wert ist in diesem Zusammenhang auch das beeindruckendste aller Architekturdiagramme. [...]
Shit this sounds like 1996 to me. There I was, pitching Java as the greatest thing ever, something that would change the way we did business. Then the reality sank in “How do we deploy it?” “How do I talk to Sybase with it?” (this was 1996 and JDBC was just being thought of), and most importantly “Is anybody going to pay me for using this?”
Time rolls onward. Ruby and RoR are now in the same position as Java was. Sure, it’s pretty slick but it’s hard to get working well with Apache: (see http://duncandavidson.com/essay/2005/12/railsdeployment)
And how do I talk to CICS with it? Are you sure everything works just as the docs say? What if I have to spend a week working around a bug?
The thing is, you and McIlree are both right (even though he sounds like an arsehole). Many apps need to be out the door quickly and suit lightweight tools and an agile approach. Other apps require compliance with obscure regulations, have to talk to oddball legacy systems and still have to keep working round the clock. These are more suited to heavy tools and a beauracratic development process. Why can’t people admit that there is more than one approach?
[...] Eine der interessanteren Diskussionen — in bester Blogmanier simultan und verteilt geführt — entwickelte sich rund um die Frage, ob man für die Lösung von “Enterprise�-Problemen unbedingt eine Technologie benötigt, die das Wort auch im Namen führt. Nicht ganz zu unrecht argumentieren die Verfechter des “lesscode�-Ansatzes, dass weniger oft mehr ist. Ausgelöst durch James McGovern, der Ruby und Ruby on Rails (RoR) sowie die dazugehörige Bewegung um den Chefentwickler David Heinemeier Hansson als ungerechtfertigten Hype und für den Unternehmenseinsatz völlig ungeeignet geißelt, hat sich neben diversen lesenswerten Beiträgen zum Beispiel von James McIlree oder Chris Petrilli auch gleich ein eigenes, abfällig gemeintes Wort für den von Kanonen-auf-Spatzen-Ansatz etabliert: “Enterprisey�, mittlerweile sogar mit eigenem Wikipedia-Eintrag. Unbedingt einen Blick wert ist in diesem Zusammenhang auch das beeindruckendste aller Architekturdiagramme. [...]
Enterprise Architects versus the World…
Robert McIllree is busy expressing his thoughts on the difficulties that practitioners of the discipline of enterprise architecture fac …...
Both comments and pings are currently closed.
Taking the enterprisey to task…
Speaking of death stars and their sympathizers, I’ve been enjoying Chris Petrilli’s meticulous deconstruction of the arguments. He takes Robert…...