I've recently come back from an implementation where I noticed
an interesting split between two groups that were going to be using
the iServer tool. The client in question has an Enterprise
Architecture team, that defines standards and reference models, and
a Solution Architecture team, that defines architectures for
specific projects. What struck me was how sceptical the solution
architects were compared to the enterprise architects.
It's a natural situation when you look at it; enterprise
architects are measured on rigor, reuse, avoiding special cases and
jury-rigs that will cause problems down the line. Solution
architects are measured on implementing their projects rapidly and
cheaply - and this usually means cheaply, within the context of
that specific project's budget and scope. So while the solution
architects may be sympathetic to the ideas promoted by the
enterprise architects, and even look to comply with enterprise
architecture policies, at the end of the day their performance is
measured in terms of getting things out of the door. Asking them to
embrace anything, such as an architecture repository, that might
endanger this is a stretch. The situation I witnessed is just one
example of the tension that exists beween doing this quickly and
doing things right, that underlies the role of EA.
So how to address this? A naive approach would be to simply rely
on the fiat - "Senior Management has signed this off, so get behind
it." But this has a couple of problems. First off, there are a
bunch of ways to undermine a fiat like this, from declaring that in
that case the project is going to get delayed by a month, to
deliberately misunderstanding how to use the tool, (how do 25
password reset requests grab you?), to following mandated policies
to the letter ("I have to do a compliance matrix but don't have to
get it signed off? OK, 0% compliant. Done."). Secondly, just
because senior management has supported adoption of an Enterprise
Architecture tool to start with, doesn't mean that that support
will be unwavering. Eight weeks of complaints from their immediate
subordinates will make most CIOs reconsider…
There's really no way around the fact that, having sold the tool
to management, you then have to go through the process of selling
it to the firefighters. But this is not as bad as it sounds. First
of all, the firefighters aren't going to be deaf to arguments based
on the good of the business. After all, a healthy business that can
respond to meet changes is one that offers job security, and decent
remuneration. So the ability of a tool to support enterprise
architecture efforts is a selling point even to the people who it
is imposing rigor on. But there are other ways that a tool benefits
the solution architects. Access Control, audit trails, security of
data…small things, but lose a weeks work just once and you'll buy
in to their value. And then there's the visibility question. Jim
may be aware that Annie is working on a project, but they may not
realise that that project is touching precisely the same area until
they notice one of their artefacts being worked on by her. Last of
all, there's the review. Most tools offer the ability to have
business stakeholders review and comment on items through a web
interface, which lets the solution architects promolgate their work
and demonstrate their efforts to include all parties.
There's a natural suspicion of tools that enforce standards on
the part of the firefighters within a given organisation, but it's
still possible to get their buy in. The important thing is to
ensure that the overheads the tool imposes are outweighed by the
percieved benefits.
One of the problems that our customers in Enterprise
Architecture often struggle to articulate to management is "Why am
I paying for this?". In other words, what is the money saving from
Enterprise Architecture governance? What is the money saving from a
tool? It's hard to give a figure that isn't plucked out of the air.
One reason for this is the 'before-and-after' problem; if
Enterprise Architecture is saving you money, unless you can
directly compare how much money something cost before to the
situation now, you can't trace how much you've saved by adopting
Enterprise Architecture practices.
In some ways it depends on whether EA is being proactive or
reactive. A proactive program of retiring redundant or duplicated
applications offers a lot more opportunity to show ROI - take the
maintenance and support costs before, take the same after, deduct
transition costs. It becomes a lot more difficult when EA is
reactive, i.e., attempting to act as gatekeeper for new
implementations. In this case, you're not actively attacking
existing spend, so where's the cost reduction? You're forced to
fall back on what for want of a better word could be called
anecdotes. That is, when you manage to identify that a software
purchase is unnecessary because a usable product exists elsewhere,
make sure you put a monetary value on it and communicate it as a
saving due to EA. If you saved costs of a z/Series box by moving to
a distributed app, then make sure that gets reported as a success
story.
A lot of architects will feel that what I'm describing is not
really their job - and they're right. What I'm describing is about
keeping their job…
Our product is diagram-based, and the EA customers we deal with
have diagrams in A4, A3 and even A2 sizes (in Europe) and Letter or
Tabloid sizes (in North America). And then there is the former
customer that I worked with once, who decided to buy a Linotype
printer to produce 4 ft by 8 ft diagrams that showed every aspect
of every system in a given area, all on one diagram. They had a
meeting room reserved with the diagrams pasted up around the walls,
so people could go in and look at them.
Now, the argument was, that by doing this you could inspect
every aspect of the area, without the need to sort between
diagrams. But I felt, and still feel, that this was missing the
point. The author of the diagram could navigate it, but noone
else could.
This gets back to the whole question of viewpoints. The idea of
a viewpoint in enterprise architecture is to show a part of the
system. Not the whole system, just the part of it that relates to a
given stakeholder or group of stakeholders. Not surprisingly, the
whole project didn't move forward in 2 years, and I'm sure that
part of that was because none of the stakeholders had
visibility.
It's all very well to go and prduce these big diagrams - or
wallhangings, as they turn out to be. Because their very size means
that they have no value in communicating to stakeholders, and that,
after all, is what enterprise architecture is all about.
In 1992, Los Angeles police were filmed beating a suspect,
Rodney King. Within hours, rioting spread across LA, and eventually
US Marines were deployed to back up the police. One incident became
infamous. Police and Marines were responding to a domestic
disturbance when two shotguns blasts came out of an apartment. The
police yelled 'Cover Me!", which in the LAPD means "aim your
weapons ready to fire if need be". Unfortunately, in the Marines,
"Cover Me!" means lay down a withering base of gunfire on the
objective - 200 rounds were fired into the apartment. Incredibly,
no-one was killed.
I like this story because while it's an extreme case, it's an
illustration of how different things can mean different things to
different people, with unfortunate results for all involved -
something that some recent clients have been struggling with. For
example, what is an application? To a systems development group,
they will often consider the application to be the ensemble of
modules that deliver functionality, but the installation group is
more likely to view the modules as applications. It's because their
responsibilities are different…fulfilling a set of requirements
versus installing and supporting systems on an ongoing basis.
This is why the concept of viewpoints, as introduced in IEEE
1471 but borrowed by everyone and their dog since then, has been so
useful for the clients above. To restate from the spec, "a
viewpoint identifies the set of concerns and the
representations/modeling techniques, etc. used to describe the
architecture to address those concerns". So a viewpoint addresses
the problem by making it explicit who the audience is, and defines
precisely what the objects are and what they represent.
For me, the real power of viewpoints, is the idea of sharing
views with stakeholders that are not the direct consumers of the
view, but who work with those direct consumers. The simple fact of
having a developer look at a system through the viewpoint for the
admin group, or through the viewpoint for the business user becomes
a valuable communication tool in its own right. It's true that this
is hardly new, or rocket science, but I'm finding that making
another group look at a system through a view designed for a
different group of stakeholder is yielding valuable insights to all
concerned.
Like any self-respecting tool, our product allows you to define
extra information fields that modelers could record against their
artifacts, say the headcount for an org unit, or the business owner
of a process. But, like most things in EA, this leaves an important
question unanswered. The question being, "OK, so we can record any
metadata we want…what should we record?". It's certainly a question
I get hit with on a regular basis.
It's a good question - if you don't record the
information, then you don't have it…but if you demand that people
record umpteen pointless fields, then they will not fill them in.
make the fields mandatory, and people look to avoid doing the
modeling in the first place. People hate to spend their time on
what appears to be a pointless activity. This means that with
metadata, less is more. You want to get to the minimum set
required. So, what fields are the bare minimum that you have to
have?
For me, you get to the answer via another question - "Why are
you doing this?". In other words, people are presumably performing
their modeling so that they or others can use the information
contained within the model. As regards the metadata, presumably
this is being recorded because it is of some use…or is it? Are you
recording the information just because you feel obliged to record
some?
What I'm leading up to is that if you are not going to use your
metadata, to search and filter, to report, to drive a
decision…then why expend the effort in recording it? This is
the method that I recommend to make the decision - for each
candidate field, ask who is going to use this information and what
are they going to use it for. If you can't identify a user, then
there's almost certainly no point in recording it.
After all, you can always add a metadata field later if
need be…or, if you can't, I know of a tool that does let you
do that…
One of our customers has adopted iServer as their master
process repository, and has mandated using our free BPMN Visio
stencil as the standard for creating diagrams. This has met with a
variety of efforts to circumvent or ignore the standard - in one
case a project has had to pay for their diagrams to be redone after
the consulting company involved chose to use a different tool and
notation. I've seen this elsewhere - usually the charge levelled at
BPMN notation is that it's too complicated, too hard to
understand, and so on.
I've never really accepted this argument. I mean, tasks
are still rectangles, flow of control is still an arrow between the
tasks, branches are still diamonds, and swimlanes to show roles are
used in several other notations anyway. For me, the real objection
to BPMN is summed up by one small project at the client above.
Their technical lead sat down with me for a 30 minute refresher on
BPMN, went away…and a week later came back saying
"You know, BPMN is hard. I'm trying
to draw diagrams in BPMN and I'm realizing there's a bunch of
things I hadn't thought about in my processes!"
That's it in a nutshell. BPMN allows you to show fine
detail - for example , you can make the distinction between a
branch where you go down both paths, or only one, or at least one.
Having this capability does pose the question of which branch you
should in fact be using.
Of course, you could argue that a good process modeler
should be posing these questions anyway, regardless of the notation
they use. I have sympathy for this argument. But for me, the value
of BPMN is that it poses such questions explicitly.
One of the original blogs was Joel On Software, by Joel
Spolsky of Fog
Creek Software. One of his many excellent posts was about making wrong code look wrong. For me, BPMN is a
step in the same (correct) direction - making fuzzy processes look
fuzzy.
Last week, I was lucky enough to attend the inaugural
meeting of the Chicago chapter of the Association of Open Group
Enterprise Architects (AOGEA). Their first speaker, Mike Fletcher
from the insurer State Farm, told an interesting story during his
presentation. After Hurricane Katrina hit, State Farm decided to
defer monthly payments from affected customers - it was a lot of
work for IT to implement, but they managed it. A couple of years
later, he was in a presentation on an enterprise architecture
initiative, and noticing the resistance around the room, he spoke
up: "You guys remember how much work it was to suspend payments
after Katrina? This is to try and ensure that next time we can do
something like that a whole lot easier". And immediately heads
started to nod.
It's something that we find in our sales presentations.
It's all very well for us to to say "our product does this, our
product does that"…but it's when we can reference what other
customers have used a feature for, that people sit up and pay
attention.
It's the nature of EA that making a concrete business case
is very difficult - "we will save $X million per year" is
immediately problematic because any such calculation has to
be based on a large number of arbitrary assumptions. In such an
environment, it becomes much easier to make a case by pointing to
costs incurred by not having done an architectural effort, or
successes resulting from architecture.
Relying on anecdotes is not rigorous, it's not a whole
bunch of neat figures…but it does have the benefit of being
truthful. I'm ever more convinced that every architect should look
to have a set of anecdotes ready to make their case.