Discontinued

This Blog will be discontinued shortly.

Ace and Architect ?

As of January 1st 2012 I have left the Oracle Ace Program.

I will always be proud of having been part of such an impressive group, and I will surely miss being an Ace Director! Let me try to explain this apparent contradiction.

First of all, I have never been a very technically oriented guy. Nevertheless, I was very lucky to be involved in doing the first BPEL implementation in The Netherlands, back in 2005. That opened up a lot of doors (mainly because we had a lot of issues to fix and needed a lot of support :P). Having a succesful implementation and a drive to spread the vision of service orientation led to an invitation to the Ace Program by Clemens Utschig, with massive support from Jürgen Kress (thank you both!). Being a part of the Ace Community has been very rewarding for me. I have met so many good people in the program, have had very interesting discussions, certainly learned a lot, but above all: got many new friends.

Over the last 2 years I have felt more and more guilty of not living up to expectations. The course of my career changed when I started my own company (MShift) in 2009, as an independent architect. Ever since that time I have been active doing Enterprise & Business Architecture. My involvement with technology declined even further. It meant I was no longer staying abreast of all the new developments around SOA Suite etc, not doing any presentations for the community, nor participating in the forums. I was participating more on OTN ArchBeat (thanks Bob!). All in all, it feels like I am no longer adding to the community.

There's another factor involved, though. I could have stayed Ace just for the fun of it, and for being able to travel to San Francisco every year to meet my fellow Ace Directors. That in itself was tempting, but ... being an independent architect becomes harder when you are affiliated in any way with a vendor. In my case, being an Oracle Ace Director often raises eyebrows on my independency and integrity. People who know me will know that has never been (and never will be) an issue. Regardless, it is more and more often that I find it to be working against me. Commercially it is better for me to become a real independent architect.

I have been thinking about this for a long time, and when we were asked to reevaluate our own position I decided to do what I felt was right: to leave the program. So there it is, in a nutshell. I have become an Ace Alumnus.

Some last words: I would like to use the opportunity to thank Oracle, the Ace Program (especially Vikki Lira and Lillian Buziak) for all their good care, friendliness, input, support, knowledge and a lot of fun. I have no doubt the Ace Program will keep on being succesful and I will try to keep in touch as much as I can.

Consensus, Leadership and Agility

Many organisations in The Netherlands are culturally consensus based, which means there's often no clear leadership, management is often seen as purely facilitating and everybody more or less goes his or her own way. It's basically the way we (the Dutch) are.

Leadership is resisted. The boss says 'Let's do this my way', and there's bound to be a lively discussion about 'better' ways to do it. Everybody (boss included) accepts this as normal behaviour.

One of the hard parts of applying architecture in such a culture is to get everybody following the strategy as it is set out in the Enterprise Architecture. How are you going to do that if leadership is resisted? What happens? A lot of architectural implementations fail due to resistance from projects.

The introduction of Agile development has increased this problem. An often heard complaint is that too much upfront architecture is a form of over-specification, which is waste in agile terms. That's true, but the argument is too often used to totally ignore architecture and just focus on the user stories for this sprint. This can result in well working applications, which do not quite fit in the strategic direction of the company. Talking about waste ...

I'm not quite sure where the solution to this problem is. One way is to define architecture in such a way that there's something in it for everybody, not just for 'the business' or 'the architect'. Another way is to evangelize, to become a thought leader within the company. Not to push the architecture through, but to convince, stimulate and enthuse all participants.

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....