Let me give you one example, at a large bank in the Netherlands, where the EA team consists of about 40 (sic!) architects. Just a few months ago they presented the latest version of the Enterprise Architecture to the management that's supposed to be responsible for implementing it. The presentation consisted of over 100 slides, the architecture documents ranged up to 400 pages. Guess what? The majority of the management dropped the handouts (classified material) in the paper bins when they got back at the office. Back to business.
There are several reasons why I think EA does not work:
- architecture is a means to an end. Architecture provides steering and control information, but is not in control!
- enterprise architecture generally takes up too much time. Companies are in need of fast turnarounds, quick solutions. No time to spend 9 to 12 months creating a baseline architecture.
- trying to fit an entire organization (depending on size ofc) within one single framework is often too much asked. It is possible to define one for smaller companies (say up to 1000 employees), but are we still talking about enterprise architecture then?
- enterprise wide scope of activities are usually doomed to fail, due to scope, size and consequences, but often due to distance between daily operations and the project itself
- EA often becomes a goal, instead of a means, especially when the teams get over 3 architects
I really think we - as architects - should be a bit more humble. We are a supporting function for the business, helping them decide what course to take and how to implement that course. Giving guidance on what works best, in practice, not on paper. Aiming for solutions that we can implement this year, not within the next five years.
I prefer to use what I call JITJEA: Just In Time, Just Enough Architecture. Yea, very original, I know. Call it Agile Architecture, where you spend very little time on the big picture, and only work out the parts you are going to need in the next couple of months. Combine this with the notion of emerging architectures, where you - as the lead architect - function as a catalyst to let the architecture emerge, and you have a recipe for an active, innovative, involved and loyal community, organization-wide! They will carry the torch where you can't or shouldn't. The architecture that emerges will be supported by many more people then you ever could've hired to staff your enterprise architecture group.
I am an EA, and have been doing it for longer than a lot of the EAs out there have been out of diapers. There are some very simple concepts that seem to be forgotten. A good EA distills the simplicity out of any situation or business. From a software perspective this is about building the "Perfect objects" - secondly, a good EA approach, is not just about the implementation of a technology. It is a precursor, to determine whether the solution is appropriate to the problem (and there should be more of not doing technology for technology's sake). It should also be the post implementation assessment. How many EAs take the criteria for design, and critically review those on a regular basis over the life of the technology. And, of course, they should be a guideline for subsequent replacement and/or decommissioning. (How many "Legacy" systems have been replaced without clear understanding of what they do, and why or how they do it).
ReplyDeleteI do agree on your reference to "big teams" - three or more, or as many as 40 EA's in an organization. I think this is more about giving people job titles, than what they deliver in terms of strategy.
I don't agree on the Means to and end, or the value of the time taken. Firstly, it's a process, not a means to an end. I have often said that the sign of a good ea, is that they never think their job is done. They come up with strategies and designs, pass them on to others to implement, and move on, revisiting them as they see fit. They are usually the folks that are thinking more in a 3-5 year plus timeframe. I have sometimes described EA's as the people who worry about the things that the CxO's haven't realized that they need to worry about yet. Secondly, with respect to the time take, as my dad said - "Measure Twice, cut once". Doing a sequence of "quick and dirties" is a disservice to the business. In some instances, (i.e. a startup) it may well suit to have a quick product to market, but if that organization hopes to retain market share, expand it's offering and so on, then, at worst, Architectural Efforts should happen in Parallel with actual engineering. (I learnt much of my craft working for a largish IT Company (that doesn't exist anymore) and this worked incredibly well, within their organization. (The company's demise was related to business/political and not technical issues.
I get nervous about your use of the term "Agile" with Architecture. Agile has a "whatever it takes/quick and dirty" connotation which is contrary to the whole concept of designing.
I see this in "Agile" Software development, where design documents, or even comments within the code base have gone by the wayside, and as such, it becomes nigh on impossible to "reverse engineer" the whys and wherefores down the track.
The Architect, as you say is a Catalyst, and leads others to carry the torch - I see this as an evangelist role. In most engagements, I find an evangelist to work for or with me. They get the Kudos, I get the Job done (and ergo the bucks...)
The JITJEA also brings to mind the old Swan Analogy - serenely swimming acorss the pond, while the feet are paddling like fury under the water. Part of the problem in this day and age, is that everyone has become an expert. In many cases, an EA needs to explain technology and or processes, with analogies that a bystander (or CEO) can understand - the problem is, that you then have people that think that they understand highly complex technology, because it has been explained to them at a very high level with a few cartoons in a powerpoint.
Hi Mike,
ReplyDeleteI agree with the suggested move from Enterprise Architecture to Enough Architecture. I'd like to add that the feedback / learning cycle of the Enterprise Architecture is almost impossible to close (due to the time required to create an Enterprise Architecture, mentioned in #2).
The level of acceptance of the architecture will be much higher when solutions and guidelines are provide for challenges at hand. Instead of a plan that tries to solve all the problems in the world...
cu
Just working on the parts you need over the next couple of months turns into a morass of systems and applications with no consistent vision. I totally disagree with your article.
ReplyDeleteI agree, but also would like to point out that the alternative - architecture that only follows the immediate need - is in itself also potentially a problem. Probably because I've mainly worked for smaller organizations, but I've seen more examples of the lack of architecture, where everything is duck taped together - if at all automated - and a lot of resources are wasted on duplication and lack of connectivity between systems than I have seen architecture becoming 'too much'. Now, lousy architecture, especially those built on the fad of the day raked together by architects who are disconnected from the technical reality is a whole other story :-)
ReplyDelete@chillenious: I agree completely. The hard part of doing agile architecture is finding the right balance between long term vision and short term issues.
ReplyDelete@anonymous: It's not either/or. You need to do both, but the level of detail is different.
@Mister Q: whether architecture is a means to an end or not, my point is that architecture too often becomes a goal instead of a process. I think the view on 'Measure Twice, Cut Once' is a bit idealistic. It's a good thing to aim for, but not always achievable.
Agile is not quick and dirty (although there's that risk), but it's a mindset towards changeability. Refactoring is a fact of life, in building software, doing architecture and your own life.
As to hiding complexity for our CxO's, that's exactly our job, isn't it? They don't need to understand the technology, but should grasp the major concepts and see possible repercussions (both positive and negative). It will, however, put additional strain on the architects.
Well, the real question is whether Enterprise Architecture is the problem, or the amount of material is the problem? Could you imagine what the same managers would do with a 100 slide presentation on HR, or for that matter on a 400 page document on the financial products they are selling?
ReplyDeleteIndeed the same as they did with this EA deliverable.
But it is a lesson that you do not want to show all your EA work to all of the people, just the relevant parts!
Paul Teeuwen, Senior Consultant IT Strategy and Architecture
Perhaps it's the centralised nature of EA, which belies the systemic nature of the enterprise. The reductionistic analysis leads to a catalogue of "elements" that bear no resemblance to the functioning enterprise and can never be "implemented".
ReplyDeleteI think if we complement current EA techniques and taxonomies with a systems thinking view of enterprises we might be moving in the right direction.
I constantly read allot of blogs that blame the process rather than the real problem. As an EA with several projects under the belt the problem to me always seems to be the individuals rather than the methodology. If you have 40 people in one project, I hope that the project is a multi-billion dollar one. In many cases reducing the number of "hands in the soup" is what gets the job done with "just enough" of everything. Ultimately what you don't want is to build the system 3 times and I'm sure we've all been there. You don't sign up for a 25 mile marathon unless you're able to go the distance and even if you did, I'm sure you'd do as much training so your lungs don't cave in by the 5th mile.
ReplyDeleteI completely agree with you. EA to the point of obfuscation is useless. At the end of the day, EA has to be about identifying and solving business problems. It shouldn't take 40 architects and 9 months to generate a bazillion slides for a readout to know that this isn't really what EA should be about. I often think the EA programs that spend eons modeling the entire enterprise in a secret room someplace are missing the point. Yes we need to understand the context within which we are operating. Yes we need a lexicon and taxonomy for describing the enterprise. But we need to do that to the point where we can begin to deliver value by solving problems. Otherwise you have a gonkulator that nobody wants.
ReplyDeleteHi:
ReplyDeletePlease allow me to link to your blog from the Light Enterprise Architecture
http://www.liteea.com/
Thanks.
Mike,
ReplyDeleteI must say that I agree with the essence of your article. It is interesting to read so many article on problems with EA and the frustration of EA specialist. It is so interesting that I have directed research activities towards a new generation of EA - named ESA - Enterprise Systems and its Architectures. (ooh yes, me too :)
The assumption is that the current set of EA framework didn't get it quite right. This based on all the problems reported in the area of management non-buy-in.
Clearly an application of a EA framework is a Mean to some Ends. Most EA are developed by and for IT people, based on the assumption that what they work with is important and of relevance to the organisation. Unfortunately outsiders (to IT dept) are often reported as unconvinced of it. Especially why EA concerns are of interested to them.
An Example from a real large B€ project where the operational people are told that SOA is how they should view services. But then relevant (to them) concerns such as (IN/OUT)sourcing falls outside the framework.
So does EA really talk business?
food for thoughts
/anders w. tell
Mike,
ReplyDeleteYou're right on target that enterprise architecture isn't working. To see why, see blog site tmiconsulting.wordpress.com. Although this site focuses on the U.S. Federal Enterprise Architecture, it exposes the underlying problems of EA everywhere. The bottom line is that most of what EA calls "architecture" ISN'T architecture.
A quote from that blog:
"The solutions to all of these problems are actually very simple, but most people can’t see them because they’ve been blinded by “illusions of architecture”:
Before we can solve these problems, it needs to be made clear that the practice of Enterprise Architecture has offered us nothing that wasn’t already available to us before in our pursuit of a federal-level understanding and management of all federal IT resources. In fact, EA not only didn’t help us in this pursuit, it has actually hindered our progress.
In our quest to “do architecture”, we have been misled by illusions of architecture. We have cast aside simple yet effective IT terminology and methodologies that have been in use for decades, and have replaced them with new but ultimately misleading terminology and bloated methodologies that are at times more complex than the problem being addressed.
We have replaced simple, intuitive, and long-used terms like “functional area” with dense, obtuse terms like “Segment Architecture” that only manage to confuse, and have developed a corresponding methodology that defies comprehension and does little to actually help us analyze a functional area.
The simple truth, if practitioners would only take the time to look into it, is that most of enterprise architecture is a facade that hides the simple solutions we need behind a false veil of “architecture".
If an organisation values IT as an investment rather than expenses then EA will give a strategic perspective and guidance to realise the returns to their investment.
ReplyDeleteI agree with you the organisation adopting EA has not always been a fruitful one as end product is often not easily achievable which require much time and resources. You have made a valid point that often Enterprise Architect has no control and no power.
Rather it takes a long vision of organisation higher management to understand the benefits and essence of EA. Often management, middle and high, do not understand that IT in an organisation is like a ship. It can be a wooden boat or a speedboat depending on how you need your ship to be. The speed and agility to support business changes fundamentally is limited to the design and build of the ship itself. One has to balance the cost of today’s incurrence to the benefits of tomorrow cost saving and business agility. Often management demands IT to produce quick solutions to support business changes but do not value IT as an intrinsic assets to the organisation growth.
It may take more education and evidence for the management and the organisation to see the value of EA. Probably to implement technology architecture (TA) for a start take involves less of business processes and business users to showcase the benefits of EA. Then move on to other areas of EA and gains valuable support by the management before EA truly establish its value in the organisation. Enterprise Architect in some degree has the responsibility to play such a role in the organisation. It is only when hearts are won then your people will follow your vision and mission.
For your cited examples that management walking out of EA presentation throwing away the EA materials only mean that at the current stage they do not understand and does not want to take part of EA. They are just not ready now but it does not mean EA is a failure. They may not be ready now it but does not mean that they will never be. EA in and organisation is ever evolving and has no end. EA may solve/control systematic problem in an organisation and truly brings about greater business efficiency.
Agile EA as what you have suggested may after all be a good strategy at least for a short term. At least some degree of EA is performed and organisation is not losing too much ground in EA perspective. However one must also exercise caution not to procedure silo EA then ultimately defeats the purpose of EA.
Derek Sum
That's it. I'm going to go back to calling myself a Sr. Business/Systems Analyst.
ReplyDelete1. By the nature of it’s being, culture is dynamic. Culture of a place changes with time. Hence, culture of the industry changes with time. Hence, culture of technology changes with time. Hence, technology architectures must change with time. Charles Darwin imparted a teaching we tend to forget too often – adapt or fade away.
ReplyDeleteIt may be a lame example for IT architects, but the fact is that the architecture perceived to be BEST suited to the technological needs a few decades ago, does not seem to work as well today, and may be a miserable failure few decades later. However that does not imply that the architects who developed the methodology decades ago, did a terrible job at it.
The debate will spur to life every time an architectural model is forced to work in times different from the times it was invented in. Today the debate is between EA and Agile.
2. Then why am I of the opinion that that EA giving way to Agile is as natural as a frog developing webbed feet? Well, historically (in software that’s barely a couple of decades), developing software at the enterprise level was a gargantuan task, as it had never been done before. Each software development mission had to be well planned, complete, documented, reviewed, structured, designed by sharp minds at high and low level – EA was the need of the day. Then what has changed today? Proponents of the EA ask, don’t we need a holistic view, or quality programming, or a strong and studied structure? When these are ignored it sure isn’t pretty. So from there originates the thought of the new age Agile lingo being but a fad which may work in a few cases but not survive the test of time and diversity.
Aren’t we forgetting something here – agreed structure and design is indispensible, but business environment has changed, technology has changed. How?
•The client can’t wait for a year, or two or more for his product.
•The client does not believe that making the software is any rocket science now. Everyone’s doing it, doing it good and fast.
•The costs of large teams, sitting over a design for months, and code for years are forbidding, and not supported by the company’s stake holders.
•The competition is fierce; they are all getting modular, faster and cheaper.
•Economical volatility where markets fluctuate, capital availability varies, government policies changing were always here, but today the response time to the changes is shorter. This means, a client wants the software development firm to be accommodating to requirement tweeks.
•Are you capable of delivering a product in phases, first to meet my requirement today, as I grow with it, I will want it expanded in scope and functionality. Or is the product such a dump of intricate code that it’ll be another project altogether to upgrade it.
•The benefit of all the hard work of the yester years’ designs is up for grabs today. There are automated utilities built on the principles developed by the learning done the hard way. Why reinvent the wheel, because the wheel works great; rather focus on the gear assembly.
•Technology changes, even while the software is being developed. Can you keep up with that, to find the best balance between low cost, low effort and effective results?
3. So what happens when I have structure and design but in a manner that has adapted to address the scenario above. Do I have a winner for this age then? EA vs Agile in my opinion is misunderstood as holistic vs local. Let’s take EA first, it does start with a holistic analysis, but has to trickle the development all the way down to the most local aspects. Now consider Agile, say the Scrum methodology. It starts with a product backlog – prioritizes it to the release backlog – thereby staying focused on the core, and setting priorities based on the business value to the customer. How the team designs its sprints decides how they channelize their focus, if it’s a large system they’d probably dedicate a sprint focused on design and analysis. This in the true sense is the agility of the Agile.
a.mendhi@gmail.com
Every organization gets the ICT solutions it deserves!!! So don't look at enterprise architects, but at the organization that employs them! See article "The business does not exist" at
ReplyDeletehttp://www.via-nova-architectura.org/files/magazine/Baarda3.pdf
(also published in the Journal of Enterprise Architecture, issue #2, 2011)
Thank you for sharing. I am curious to how you feel about enterprise architecture now, almost three years after this post. I think EA is crucial for any business.
ReplyDelete