Why Enterprise Architecture Doesn't Work

I really think Enterprise Architecture does not work. First of all, I have never seen a working example. All Enterprise Architecture Departments I know (a lot!) are very good at generating enormous amounts of paper, but generally not so good on achieving results. The added value of the architecture function is marginal.

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.

Governance Causes SOA Projects to Fail?

I got spammed with a mail about a Methodology for SOA that contained a very intriguing thought:

.. it is not poor governance that causes SOA failures but rather governance itself is a single point of failure and a pessimistic organizational structure that causes SOA to fail.

It reminded me about a presentation I attended at the LAC 2009 conference, by Frank Schalkwijk (Atos Origin), on Emerging Architectures. He argues that it's better to 'engage' our specialists than to 'govern' them. That way an architecture can 'emerge' with a lot more support in your organization. Hmmm.

Architecture and Agility

Last night I had an inspiring dinner with one of my old colleagues, Ronald Doelen. We both see more and more companies changing their project methodology from waterfall to agile. We're both very enthusiastic about that, even though there are some hurdles to take, like architecture for example.

All and good to go Agile, but if you're stuck in an analysis-paralysis situation with your architecture, you will not reap the benefits that Agile brings. You might get away with ignoring the architecting issue - at least for the short term - but it will catch up with you in due course.

So, the answer: Agile Architecture. That got a nice ring to it, but what and how? It all depends on how you look upon architecture and the role of the architect in the company. At the end of our meal - not quite as good as our discussion, tbh - we came up with a number of statements that we'll take with us to work on in the near future. Let me share a few of our thoughts:

The role of the architect in your organization is often determined by the culture of your organization. The architectural style (ivory tower, magician, counsellor, architectus reloadus) determines how you need to adapt your agile projects to align with architecture. The more agile the architect, the less impact.

Architecture is nothing more (or less) than a (limited!) set of choices and the accompanying motivations. Often architects worry about making the best choice. In case you didn't know it yet: there IS NO BEST CHOICE! There's just choices, all with consequences. Use risk-analysis to determine short and long term implications of your choices and base your trade-offs on them. But limit the choices to those you really need NOW.

I'll spend some more time thinking about Agile architecture and especially how to align Enterprise Architecture with Agile projects. I still see some challenges, but will take about those later.

Here Goes the Sun

A lot of people have been wondering lately what will happen to the different products from Sun. Will they be incorporated into the Oracle stack, or phazed out altogether. It is one of the questions I have had myself. According to the webcasts on the Sun acquisition it seemed that:

GlassFish will continue as the Java EE reference implementation

GlassFish Server included in every Oracle WebLogic Server offering

Sun Java System Web Server will be part of the new Oracle Web Tier offering.

As the Glassfish ESB becomes more and more popular, one of my current customers was very interested in using the Glassfish ESB. Looking over the Glassfish website we got the impression of a fully supported product.

Nothing surprised us more however, when we asked Oracle for a solution package of Glassfish ESB. We received .......... an offer to use Oracle SOA Suite. Further inquiries to Sun learned us that "we're not allowed to offer Glassfish ESB solutions anymore".

So it seems that the choices have become clear, at least within Oracle.

Managing Data and System Integrity in an SOA environment. Are You Prepared?

One thing that worries me a bit, is that you hardly find any discussion on data and system integrity in an SOA environment. At least, I don't see many. To me, data and system integrity is the most challenging issue we face today and the days to come. We will see more and more combinations of Services, SaaS, legacy apps, which will make a 'standard solution' to this problem even more relevant.

Lots of vendors I talk to tend to minimize the problems of integrity and robustness. They point at their infrastructure and say: well, our infrastructure is WS-Transaction compliant, you will not lose any messages. OK, that may be true, but will it fix failures? You can guess the next comment: with our high availability strategem, we can ensure a 99,99% availability, so you need not to worry.

Despite their reassurances, I still tend to worry: 99,99% availability is not 100%. Things can still (and will!) go wrong.

Let me try to explain the issue as I see it. A very simplistic example:

Service A calls Service B to execute a process. During execution of Service B it calls upon Service C to handle financial details.

Suppose Service B needs to be restored to a certain point in time because of an internal failure (does it really matter what caused the need for in-time recovery? I think it does ...). What does this mean for Service A, B and C? What kind of functionality do we need to have in place to make sure the entire system will not lose its integrity? How do I make sure that Service B 'catches up' with Service A and C? One might argue that due to the statelessness of a service, this shouldn't be a problem, but it is (besides the fact that there's loads of statefull services out there).

This used to be no problem in our legacy application environment. You just rolled-back the whole system and started all over again. However, our boundaries have become much smaller and larger at the same time. It is still a valid approach within a service boundary, but not in an SOA environment (which has no clear boundaries to begin with). Especially as you use services that might not be under your control (SaaS vendors, chainpartners, etc).

My worries come from the fact that most companies I visit, do not have a strategy to maintain this integrity. Mostly, they do not even acknowledge this problem, until they are confronted with it in real life. Suddenly it's become a major problem, because it is very hard to determine what to do, but there's a lot of pressure to fix it right this very minute!

What we need to keep in mind here, is that it is not just a technological problem. It is functional as well. How does the business wants to respond to failing (internal or external) components?

Luckily, having a good middleware infrastructure mitigates the problem somewhat, so it is possible to reduce the problem a lot, but especially in high-volume environments you really need to have a well thought and tried-out strategy in place. There's no falling back to manually fix things when you're processing thousands of transactions a minute.