Normative Restriction of Design Freedom

I've been working on creating an environment to document an architecture. The customer I'm working on at the moment, has a lot of documentation, but it's all spread over powerpoint presentations, word documents, enterprise architect models, archimate models, visio diagrams, excel spreadsheets and wiki pages. You can imagine it's a tough job to find all the information you need to make choices. So, I have suggested to rationalize all these documents into a Wiki, which will then be the 'Single Point of Truth' concerning the company's architecture.

That's easier said then done. The most important question here is what to document. Document too much and you'll never get anything done, document not enough and people will not know what to do or how to do it. I looked at all (well, not all, but a lot) the architecture metamodels around to see which one of them would give me the structure I needed. Unfortunately, most architectural models ignore concepts like business goals, principles and construction regulations. To me that's quite strange, as I find that these are essential parts of any architecture.

About two weeks ago a NAF workgroup (Dutch Architecture Forum) presented its results. A book on Architecture Principles. In a very lively presentation the authors Danny Greefhorst (ArchiXL) and Erik Proper (Tudor) presented their book, accompanied by two organizations who participated in the research. I'm not going to discuss the book here, as I'm still in the process of reading it, but it did trigger me to re-think the work I had done for documenting architectures.

One of the essential conclusions of the book (and hence the presentation) is, and I quote:

The meaning of enterprise architecture is that it provides a normative restriction of design freedom toward transformation projects and programs

This is a very interesting concept. The more I thought about it, the more I think it is a concept that I could use in my quest for the optimum architecture documentation metamodel.

Luckily I was able to discuss both my quest as well as the book during an IT-eye Open Space. After more than hour of (sometimes) heated discussion we came up with the model you see here on the right hand side. In that model you will find the 3 basic artifacts I think every architecture needs:
1. Business Goals - what needs to be achieved in the next 5 years
2. Principles - what are the (business, information, technical, etc) principles that guide any change within the organization?
3. Construction regulations - what do we have to comply with when constructing artifacts (like processes, datastructures, business units, software,etc).

I have added the 'Generic Components' as well, as every organization has reusable artifacts (reuse is not limited to software!). The fun part of this model is, that you can look upon each and every relationship that's drawn in it as being of the type 'Normative Restriction of Design Freedom'. Business Goals, usually the highest level, is (often severely) restricted by the existing environment. Change comes harder if you have to replace existing constructs. Business Goals themselves restrict Principles. It won't do to have principles that go outside the set goals.

So now I have a potential metamodel which I'm already applying at my customer. It will probably need some more finetuning, especially taking in account specific characteristics of Wiki functionality.

What Happpened to the Designers ?

A couple of years ago a lot of job names in The Netherlands changed. One day it seems, it was no longer acceptable to call the lady who cleans your house 'cleaner' but 'interior caretaker'. A farmhand became an 'agrarian assistant'. I really don't know why. At the time it looked like it was aimed to change the perception of less-liked jobs. Maybe to increase interest?

These days, everybody is an architect. Process Architect, Software Architect, Information Architect, Infrastructure Architect .....

I experience a devaluation here. I see lots of 'architects' designing applications (making process models, logical data models and use case models, etc), abusing the PSA (for those without IT background: Project Start Architecture) for the job. Even worse: a lot of people and organizations think that's what architecture is all about.

Depending of the level of architecture, an architect should set out the framework, the guidelines for the solution, not the lowest details of the solution itself. He (She included) should focus on the consistency of the total solution for the enterprise, making sure that no effort goes to waste, but delivers to the long term goals of the organisation.

That also means you don't need a whole army of architects. Just a few (depending on the size of your organisation), assisted by a minor army of designers, would do the job!

What or Who's Driving Architecture ?

All too often I'm hired by the IT Department. First thing I usually have to do then is argue my way into the 'business side' of the company that hired me. After all, Architecture should be a business issue, not to condone IT strategy. Usually IT management grudgingly agrees.

But, when architecture is initiated by IT management, your work is a lot harder. I find it is really one of the hardest part in doing architecture: business often doesn't really care, and IT cannot sell the idea of architecture. You will have to overcome the suspicion of the business. That will take some doing, as nobody is really waiting for you. Make sure you're not on a mission to sell the IT strategy to a business that is a) not interested and b) doing a whole lot of other - more interesting - stuff.

So you really need to make clear to the business that what you're trying to achieve is aimed at achieving (long term) business goals. At the same time you need to stay on good terms with IT management, as they're picking up the bill for your hours. Another kind of trade-off than we're usually used to. The hard - but fun - part lies then in finding the balance between business and IT goals.

Sometimes you're in luck. Business is so pressured into change that it will welcome anyone who can assist them in realizing that change. But don't get used to it....

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.