30 October 2009

The EA Identity Crisis

As business architecture gains a foothold as a tool for enabling the delivery of business change, Enterprise Architecture (and more specifically the Chief Architect) is experiencing an identity crisis.

IT’s Coming Home
With the fairly recent and somewhat belated recognition that Enterprise Architecture is not a purely IT focused activity (the clue is in the name), architects are finding themselves more involved with the alignment of IT architecture with business strategy. In some organisations, there may even be the recognition that Business Architecture is key to this transition.

Why this is considered to be something new is beyond me. Why IT would consider alignment with the business to be an add-on or a refinement to what they currently do is extremely worrying. The history of how IT became something separate, and how the need to “align IT to the business” arose as a task that people needed to be reminded of is a vague one that I will not discuss in this post.

I need to stress at this point that I do not accept that an amorphous reference library containing all the compartmentalised business information and design in any way represents a true Business Architecture; no matter how many times people try to call it one.

The emergence of Business Architecture as a formal activity should not be in an issue in itself. It is a fairly simple matter to realign architecture to the business needs, and use existing Enterprise Architecture skills to articulate the Business Strategy as architecture, and then derive the technology oriented elements of the architect from this...

...but it is an issue.

Get your Filthy Hands off my Business!
Despite the addition of the “enterprise” qualifier, architecture is still considered in many organisations to be purely the domain of the IT department, whilst business strategy is considered to be something that IT may be interested in, but should not interfere with. It is here that the dilemma exists.

The main cause of the confusion is the alignment of many Chief Architects to the IT Department coupled with a reporting line up to the CIO. It is difficult for such an architect to be considered as anything other than an IT focused individual, and it is then even more challenging for this individual to get a seat at the business table. However, for many problems, IT forms a major part of the solution, and in developing an enterprise architecture, the Chief Architect will need to have a working knowledge of the emerging technologies that so dictate the art of the possible in the modern world.

Now we need to address another misconception. Apparently, IT people don’t understand the business. This is as unreasonable and offensive as saying women can’t drive or white men can’t dance (and more seriously, it is a form of discrimination that can damage careers). Of course, some IT people do not have the business savvy to become enterprise architects, but similarly some non-IT people do not have the engineering mentality that is core to the development of a simple, well structured architecture (and vice-versa).

However, this discriminatory belief that IT people aren’t fit for business matters, often excludes architects who have grown up through the technical ranks from contributing to, or guiding the development of Business Architecture. (I have seen job adverts for Business Architects that explicitly request that candidates must not come from a technical background).

So we have two questions to answer. Firstly, who is the Chief Architect for the enterprise as a whole, and secondly, who does this person report to?

Who Am I?
I am aware from my conversations on twitter that some people have come to the conclusion that the CEO is the Chief Architect. In my opinion this conclusion is not a practical one; despite the fact that it is supported by more than one person whose opinion I respect. For me, the CEO is chief visionary (or strategist) and of course has control over the architecture, much as he or she has control over all elements of the Business.

But the CEO is no more Chief Enterprise Architect than he or she is COO or CFO. Architecture is the next step in the process that takes the CEO’s vision and formulates it in an unambiguous and concise manner to guide the “doers”. (See my previous article What’s in a Name?). In any organisation large enough to need an enterprise architecture, for practical reasons the role of Chief Architect needs to be a delegated post.

Where Am I?
If the Chief Architect is aligned to IT through a reporting line to the CIO, then discrimination may prevent them from including Business Architecture in their remit. If the Chief Architect is outside the IT domain reporting directly to the CEO, then there is a danger that they become separated from a core function that will be involved in a large element of each business change (the IT part).

For me, there is no ideal solution, but in the current climate of business discrimination against the technically minded, I believe may be necessary for the Chief Architect to be recognised as a direct report to the CEO.

If the discrimination can be overcome, and if the business has a strong technical element within its solutions, then there is no reason why the Chief Architect should not report to the CIO, and the role of CIO be recognised as more than just an IT centric one.

What Am I?
As far as hard skills go, the Chief Architect must have a broad range of practical experience, aligned to the typical proportions found in the business solutions. Inevitably, where businesses are adopting highly technical approaches to their problems, the implication is that the Chief Architect should have a rich technical understanding, and if this means they come from the ranks of IT then this should not be seen to be a problem. As far as soft skills are concerned, here is a brief (but not complete) list of those that I feel are important:
  1. The ability to communicate at all levels and to a variety of audiences in a variety of ways.
  2. The ability to influence by recognising the needs and motivations of others.
  3. The ability to see the big picture quickly and intuitively.
  4. The ability to work with uncertainty and create certainty for others to work with.
  5. The ability to rapidly assimilate new information (no-one knows everything, but an Architect needs to know everything that is relevant).
  6. The ability to make decisions (a surprisingly rare skill).
  7. The ability to solve a problem in a manner that is beneficial to the needs of all parties.
  8. The ability to recognise simplicity at an aesthetic (instinctive) level and avoid complexity.
“But techies don’t have the necessary soft skills!” I hear you cry. There we have the generalised and unacceptable discrimination again. Of course, the Chief Architect does need many soft skills, and these skills may not be abundant in the technical community...

...but that is because as a set they are not abundant in any community. What is more, close inspection of the list should reveal that all apart from the first two skills in my list would be recognised by most engineers, technologists, and IT practitioners as core to their profession.

In Conclusion
Get rid of the anti-tech discrimination (techism?) and the problem goes away. Changing reporting lines will not solve it. Perpetuate the discrimination and you prevent a significant number of excellent candidates from contributing to a key business focused activity in your organisation.

Place all your architecture activities under one single Chief Architect and thus centralise and coordinate one of the key activities you have at your disposal to transform your business. Allow this architect to embrace all elements of the Business (IT included) to develop a truly enterprise wide, fully inclusive architecture.

Before you can truly decide who the Chief Architect reports to you need to fully understand what the true role of the CIO is (and that, my friends, is a whole new topic).

Regards
The Enterprising Architect

20 October 2009

Is it All Just Smoke and Mirrors?

Where does enterprise architecture sit in the grand scheme of organisational change?

I Have Nothing up My Sleeves
One of the most common criticisms levelled at architecture is that it resides in an ivory tower obscured by clouds. Another is that architects are just “making it up as they go along”.

I feel we can quickly dismiss this second criticism, as this is exactly what architects should be doing (or to put a more positive slant on it, making key decisions, and defining strategy in concrete terms). They should, however, ensure that they are “making things up” before people need those things to do their job. Just-in-time architecture is a good thing, but it is only a small step towards just-too-late architecture, which by definition is too late.

There are More Questions than Answers
The first criticism, however, is less easy to dismiss, primarily because in many organisations it is very much the truth, and it is this issue that is key to understanding where architecture sits in the organisation. The activity that is referred to as architecture frequently fails to deliver the key things that it must provide to be of real value, and those things are answers. And now, some brief reminders:
  1. Principles are not answers.
  2. Guidelines are not answers.
  3. Option papers are not answers.
  4. Concepts are not answers.
  5. Answers that have no basis in reality are not answers.
Real architecture is not about vague concepts; it is about concrete reality. It converts the vagaries of strategy into clearly articulated and unambiguous answers that allow the doers to get on and do. One of the key goals of architecture should be to get to the answer as quickly and as simply as is possible.

Between a Rock and a Hard Place
Real architecture sits firmly between strategy and projects and is essential in bridging the gap. If architecture looks only towards strategy it fails to drive delivery. If architecture looks only towards projects, it fails to inform and challenge strategy. In essence:
  1. Strategy tells you what you need to do.
  2. Architecture tells you how to do it.
  3. Projects have the hardest job of all; doing it.
It is for this final reason that architecture must ensure that it makes this incredibly difficult job just a little easier by removing much of the uncertainty of strategy before a project encounters it. This leads me to my concluding list:
  1. By refining strategy, architecture challenges and refines that strategy, removing the conflicts and ambiguities. It turns ideas into answers.
  2. The to-be architecture allows the business to identify the largest gaps in the delivery of its vision, and this in turn helps to inform priorities.
  3. Architecture is a revitalisation of the age old skill of back-of-a-beer-mat design. If you can’t draw it, it isn’t real.
If architecture does not do these things then it is not worth doing.

Regards
The Enterprising Architect

19 October 2009

Simplicity: Art or Architecture?

Is it useful to think of simplicity as an instinct and Enterprise Architecture as an art form?

The "Wisdom" of Crowds
There seems to be a popular "wisdom" that systems (business and/or technical) develop through a process of evolution, and evolution inevitably leads to complexity. Proponents of this wisdom use nature as an example in all its glorious variety. This in turn leads to a fatalism that accepts complexity as a necessary evil, and attempts to manage it and cater for its existence.

Well, in my opinion, wisdom is rarely common, and never more so than in this case.

Natural Selection
Evolution involves two key processes. The first is change, and the second is selection. In nature, the selection process acts purely on survivability, and takes no account of cost or complexity (why should it?). In nature there is no dominant competitive advantage that encourages simplicity. In business we have the power to create the model, and the selection criteria are under our control.

So when is the best time to remove complexity? At the point of creation, of course. We need to create a force of natural selection that weeds out complexity at source.

Architecture is the first point at which visionary statements start to be converted into realisable decisions, and so architecture should be that force of natural selection. Certainly complexity cannot always be avoided. It will always be lurking in the background waiting to sneak in as soon as we take our eye off the ball, and any complexity within the architecture will only breed increasing complexity in its delivery.

If the “to-be” architecture lays out a simple future and we ensure that delivery efforts are always directed towards that destination then it will be simplicity that will evolve instead of complexity. Essentially prime responsibility lies with the Enterprise Architect to ensure that simplicity is achieved in everything the Business does.

Simplicity should therefore be one of the key quality criteria for enterprise architects to focus on, but how should we measure this simplicity?

It’s all in the Mind
Most human beings are driven by an innate sense of aesthetics. They are drawn to that which they find pleasing to the eye. Most architects are no different, and try as they might to claim a logical basis for each of their decisions; this aesthetic drive underpins much that they do.

Do not fight this.

Aesthetics is an important factor in any architecture as it allows you to use your innate skills to produce answers far more rapidly than might otherwise be possible.

Consider as an analogy the act of catching a ball. If you relied on trajectory calculations, and information relating to the launch velocity and angle of the ball, the task would be impossible within the timescales. Instead, through practice, the human brain manages this task in a far more reflexive and responsive manner.

The Eye of the Beholder
Unfortunately beauty is very much in the eye of the beholder. Just as one persons Turner prize winner is another’s childish scribblings, some find beauty in simplicity and will strive for it whilst others are attracted to complexity, and will revel in it. If you fall into the latter category you probably will not make a very good architect, until you can curb this tendency.

Another form of beauty arises from symmetry, but the case for or against this is not as clear cut. I have experienced situations in which questionable elements of an architecture or design come into being simply to balance the diagram. I have also discovered gaps in an architecture as a result of the asymmetry that their omission creates.

However, assuming that you can tune our aesthetic sense to simplicity, and use symmetry constructively, it should provide you with a powerful tool for accelerating the development of your architecture.

Architecture as an Art Form
So, am I suggesting that Architecture is an art form driven more by creative urges than by raw logic?

Yes, I am.

There are, of course, numerous metrics and processes out there that claim to provide a scientific basis for measuring and controlling complexity, and I am not denying that some of them do actually achieve that goal in theory. In practice, however, such a method driven approach is too laborious to deliver results in the short timescales typically necessary for the resulting architecture to be of value.

We need a more pragmatic, and dare I say it agile approach. It is for this reason that I would encourage all architects to develop and trust in their innate aesthetic ability in order to ensure that their architectures are elegantly simple.

It is only through this development that they will be able to deliver effective architectures within sensible timescales.

Regards
The Enterprising Architect

16 October 2009

When is an EA not an EA?

In no particular order:

It Is NOT an Enterprise Architecture if...
  1. Your CxOs don't know what it is, and don't care what it says.
  2. Your strategic thinkers do not agree with what it says.
  3. It covers one area of the Businesss without considering the whole (and yes, IT is one part of the Business).
  4. It does not start with a single big picture that can be drawn on one piece of paper (and still be legible).
  5. There is more than one of it. (Question: "Do you have an EA?", Answer:"Oh yes! We have lots!").
  6. It tells you what the present looks like without telling you what the future is supposed to look like.
  7. It tells you how to work out the answer instead of telling you what the answer is.
  8. Using it is a burden for your projects instead of a boon.
  9. It is easier to ignore it than it is to follow it.
  10. What it says has not been agreed with the business leaders.
  11. It can be interpreted in many ways to suit many agendas.
  12. No one is looking at it and saying "That's it! That's what I wanted!".
  13. You cannot implement it in stages.
  14. It takes many people and many months to develop before it becomes useful.
  15. It is deemed to be complete. (My work here is done *whoosh*).
  16. You have to understand all of it before you can deliver a part of it.
Regards
The Enterprising Architect

15 October 2009

For Sale – Bijou Architecture in Attractive Location

I have often heard architects complaining about the amount of talking they have to do. They seem to be stuck in an endless round of communication that takes place to sell the concept of architecture to detractors, to describe content of the architecture, and to explain how it should be used.

And for those that are successful in this exercise there is the challenge “Okay! I get it now – so why haven’t you done it yet?”

Architects then hold their hands up and bemoan the obvious catch-22 situation, but are they right to complain?

Put simply, no.

It’s that Pesky 80/20 Rule Again
I firmly believe that architecture is 20% creation and 80% communication. The primary role of architecture is to clearly and unambiguously articulate future strategy, and so the one thing it absolutely must do is communicate! A badly communicated architecture is a failed architecture (no matter how good the concepts within it may be).

So how does that 80% stack up? You might think it sounds like an awful lot of talking, but let us not forget that not all communication is verbal. What is more, not all communication is focussed on selling the architecture; the content has to be communicated as well, and it is in this latter dialogue that the other forms of communication can play an important role.

The Picture on the Box
As far as possible, a good architecture should be self-explanatory, thus freeing up the architect to focus on the act of selling. Communication of content should be visual supported by descriptive text, with verbal backup where necessary to break people in gently.

Clear visual communication requires a solid unambiguous notation. It is not good enough to simply use boxes and lines of your own choosing with no consistency, as you will then fail to perform one of the key tasks of architecture – to remove ambiguity. An off-the-shelf notation is perfectly good enough for most purposes and has the advantage that you then have one less problem to solve yourself.

My preference here is ArchiMate as it is simple, effective, and specifically oriented towards architecture. I feel it also has a reasonable chance of being more widely accepted, given its adoption by the Open Group. If and when a genuine standard emerges, I would recommend its use over all other options, as a widely recognised notation is of enormous value. However, in the absence of such a standard, the actual choice does not matter, as long as the notation is easy to follow, and each symbol means one thing and one thing only.

It’s not an Exam
One of my chief hatesis when reasoning and justification are included within the architecture itself. I dislike having to trawl through reams of text that states why something is the way it is, to finally get to the actual decision.

Remember, you are not trying to pass an exam. It is the answer that should leap out at the reader, not your thought processes. If your selling activities have been successful, then the reader of your architecture should already be receptive to the content. If they are not receptive, then no amount of cajoling at this stage will win them over.

For example, if you have decided that you are going to have one central information store fronted by a set of business focused services then just say that in a simple diagram. An architecture is not a crime novel – you can tell the reader who the killer is on page one without spoiling the surprise.

Selling the Architecture
And so we come to the other element of communication. Selling. Architects generally ask three simple questions at this point:
  1. The business has hired me to do this. Why should I have to sell it to anyone?
  2. I can’t possibly talk to everyone. Who should I sell it to?
  3. I’m pushed for time. How do I get buy in quickly?
The answers are equally as straight forward:

Why? Self Interest
It is essential to remember that if people don’t use your architecture, and people don’t contribute to it, it will fail and so will you.

On a more positive note, most of the people you talk to will remember you. Not many people are offered such a genuine opportunity to network with the movers and shakers within an organisation, so make the most of it.

Who? Leaders and Doers
(This is the bit where I upset various layers of middle management).

The first group of people you need to sell to is at the top of the food chain – the true leaders. If you are lucky enough to have the ear of the CEO or CIO then you have a much smaller (but potentially more challenging) task. In most cases this will not be the case, but I would strongly recommend that you need to target those with real influence. In most large organisations this is at the Director and/or Programme Manager level.

Win over this audience, and they will tell their middle managers to follow suit.

The other group you need to sell to are those who will use your architecture in anger. These are the people who will suffer the pain of a bad architecture (and this is their fear), or more importantly these are the people whose lives a good architecture can improve. Talking to these people will really test whether what you are doing with your architecture really does deliver the benefit you are claiming, so listen to what they have to say, and show that you are reacting to their feedback. The wisdom of crowds is powerful, especially when it is your wisdom.

Win over this audience, and they will carry the torch for you, selling the use of the architecture to their middle management, and engaging with you during their day-to-day activities.

In other words, catch your middle management in an architecture sandwich.

How? It’s all About Me!
There are so many ways you could sell your architecture, and the most common is the one I call “Architecture will save the world”. In this approach architects unveil impressive lists of benefits to the organisation, the customer (and now the environment), bombarding the audience with the undeniable world shattering importance of architecture...

...and get nowhere.

These architects are failing to understand one of the most fundamental elements of human nature and motivation (one I have alluded to earlier in this post) - Self Interest. Even the most generous amongst us will instinctively resist anything that will cause us pain (apart of course for the masochists who are often already architects).

If you tell your audience only one thing, tell them this: what it does for them. Understand their pain points and their motivations, and look for ways in which you can make their lives just a little less painful. Point out how much time your architecture will save them, show them how it will help them to get buy in for their work, point out where the answers to their problems are, and don’t forget to explain how their contribution to it will gain them recognition.

Point out that the decisions in your architecture have already been agreed with senior management, and by using the architecture they will not have to justify every tiny little thing they do. Use actual examples from the architecture to illustrate your points, and better still (if you are far enough down the line), bring along a willing champion who has already used your architecture.

Oops!
What do you mean when you say, “my architecture doesn’t those things”?

Maybe I forgot to mention the first step in selling...

...make sure you have something that people want to buy.

Regards
The Enterprising Architect

5 October 2009

Find me an Enterprise Architect!

Or… how do I know that the person sitting in front of me really is an Enterprise Architect?

The Princess and the Pea
Once upon a time in a kingdom far far away, the King and Queen needed a wife for their son the Prince, but there were no princesses. One windy night, a girl arrived at their castle soaked and dirty, claiming to be a princess.

Hurrah!

But what if she wasn’t a princess?

The King called for the wise woman, and explained his dilemma. The wise woman told them to place a pea beneath the mattress on which the supposed princess would sleep. If she knew the pea was there, then she truly was a princess. Sure enough, the girl passed the test (despite ten mattresses being piled one on another). A princess had been found, and the Prince was finally married off.

If only there was a similarly straight forward test for an Enterprise Architect…

Can I see some ID, Please?
Maybe there is? If you examine the job market, it would appear that there are certificates out there that do the job. A quick trawl of the internet reveals a variety of bodies offering Enterprise Architecture certification. A sample of these organisations is listed below:
  • The Open Group
  • The Federal EA Certification Institute
  • EA Center of Excellence
  • Global Enterprise Architecture Organisation
These certificates certainly claim to take some of the guess work out of distinguishing the true Enterprise Architects from the impostors, but what exactly do they actually prove?

I have to admit at this point, that I approach this subject from a position of extreme bias. In my opinion and experience, many of these certificates can be obtained fairly easily after a quick training course followed by an exam. This very fact indicates their true value (or lack of it). You do not become an engineer in a week, nor do you become a solicitor after a quick correspondence course, so why get an architect badge in this way.

Certificates of this type are meaningless, but they do create a ready market for training companies to churn out a course to an eager market (especially if you persuade a large organisation that all their people are architects, and all their architects need a certificate). What is more, an easy to obtain certificate devalues the very profession it is trying to support.

There are more Questions than Answers
And then there is the question of what type of architect are we certificating for? Most certificates are IT related, so where does the Business Architect feature in all of this? Do we need one for each type of architect, and then by whose framework do we judge that these architects exist as separate entities. There are then certificates to support specific architecture frameworks such as TOGAF.

Collecting architecture certificates could become a full time activity, and the prospective architect might still not possess the actual certificate required by the organisation for which he or she is intending to work.

Certificates (if of use at all) are best suited to specific subject areas or activities. An example from the building trade: In the UK, plumbers can (and must) obtain a certificate that permits them to fit pressurised hot water systems. Enterprise Architecture encompasses a wide variety of activities and disciplines and can be executed using many different frameworks. Certification is not an appropriate answer.

You Have Much to Learn, Grasshopper
If a certificate isn’t the answer, perhaps there may be a more significant qualification that would fit the bill. Consider an MBA - a significant and widely respected qualification in the business community. I have also been reliably informed that there exists a one year conversion qualification in Law that entitles a recipient to practice in certain areas of the legal system. Surely something like this might make sense?

Interestingly there is already at least one such course, offered by the RMIT University (Australia), entitled Master of Technology (EA). Obviously, the title implies that this is IT focused, but perhaps this is a potential route?

I do not feel that the analogy holds true here, and I have my doubts as to whether EA is really big enough in itself to justify such a postgraduate qualification? Business and the Law are two huge topics with many strands and specialisations. The addition of a masters level qualification makes sense in this context. Similarly, a masters qualification in engineering makes sense as once more this takes a huge subject to a new level.

I would expect Enterprise Architecture to start to feature in these higher qualifications (especially the business and engineering related ones) as one of many topics to be considered, but to study it as a subject in itself does not make sense to me.

Seek and Ye Shall Find
So, if I believe that certificates are not the answer and further education does not fit the bill, then how do I propose that we separate the wheat from the chaff?

What we really need is something significant that builds on the existing higher education structure. Something that reflects the educational and employment history of the individual, and that describes their wealth of experience leading up to and including their activities as an Enterprise Architect. This needs to be backed up with a list of real references from those for whom they worked, and finally we need an assessment to ensure that the candidate is a good fit for our organisation.

Hmmm…   Isn’t that a CV and an interview process?

Regards
The Enterprising Architect