Zooming in from 50000 feet

It was definitely one of the more…interesting questions to be asked on the last day on a customer site. "So, Peter, you've defined a roadmap to take us now, in the last week of January, to a TOGAF-based current state architecture by the end on March. How can we achieve that by early February, because I've just had an email saying that's likely to be the case?"

I'm pleased to say that I didn't make comments about preparing three envelopes.

In actual fact, something like this represents an opportunity. A common problem  that I've seen is paralysis by analysis - where a TOGAF implementation manages not to produce something because of the sheer volume of information that is involved in documenting a current state. Eventually the higher ups demand to see what useful insights have arisen, the analysis is still ongoing and the project gets canned as a waste of money.

This is a natural consequence of the the kind of people involved. Architects, by their nature, are detail-orientated. The devil is, after all in the details. Business managers, in contrast are not detail-orientated, and in particular, have trouble visualizing things from an abstract proposal - they need concrete examples. It comes from juggling umpteen balls at once.

Which brings me back to mission impossible from the start of this post. There is no way that they could accurately describe an enterprise in 3 weeks in TOGAF…but there's no reason why they couldn't describe the big picture. Top-level organisation A delivers top-level services B, C and D, which uses top-level systems F and G, which live in datacenter H. Your apps catalog may have 10 entries instead of 350; your technical architecture considers datacenters or banks of servers, and not individual servers…but this can be iterated later on, to add detail, to replace the coarse-grained relations with finer ones, replace high-level systems with lower-level modules, and so on.

And in the mean time, your business users can see the 50000 foot architectur and finally 'get' what it is the architecture team do for a living.

Rahm Emmanuel: Enterprise Architect

It's interesting how a single remark can follow you around for the rest of your life. I wish I had ten pounds for every time somebody quoted Rahm Emmanuel's comment on the financial meltdown - "Never let a serious crisis go to waste. What I mean by that is it's an opportunity to do things you couldn't do before." What's interesting is the sheer number of times I've heard it from people working in the enterprise architecture space.

Here's the problem with a lot of enterprise architecture - the savings are no-attributable. Which is to say, restructuring an application provides flexibility for the future, but even if you can quantify the value (not always certain), can you trace the value against the architecture effort? In such an environment, it's difficult to cost-justify this kind of undertaking - without the support of a long-range vision at the C-Level, it's not likely to happen.

Let's face it - most organizations aren't like that. If you're in such an organization, there's little or no scope to improve the architectural foundations of the business - unless you do it by stealth. Here's where our friend Rahm comes in.

Most architecture departments that I've seen are basically firefighters. They are called in on projects to fix specific identified problems, after they become problems. So, the only opportunity to do proper enterprise architecture is going to be under the auspices of these projects; add in some extra tasks that the project could perhaps bodge through without, but which greatly improve the future operation of the business. The only trick is to not be too ambitious in such an undertaking and get it under the radar.

Unethical? Perhaps, but given that the inability to engage in proper enterprise architecture arises from a short term fixation on stock prices and bonuses by senior management, instead of looking after the long term interests of the company…is this a case of correcting a wrong , not perpetrating it?

PEAF – a first look

In amongst the frameworks of Zachman, TOGAF, DODAF, MODAF, FEA and so on, there is PEAF (Pragmatic Enterprise Architecture Framework) - a relatively recent addition to the crowd. After a first look, I have to say it seems like a valuable addition.

The key thing that you notice going into PEAF is that it's very light on models compared to, say TOGAF. In TOGAF, the methodology for how to create and implement your models, the underlying metamodel, the list of deliverables and artefacts are front and center. There is consideration of how this needs to be informed by principles, of how the architecture needs to gain the support of senior management, of how the whole archietcture effort needs to be governed…but this area rceieves a pretty light treatment in comparison to the actual archietcture modelling effort.

PEAF, in contrast, has a clear emphasis on how do you get buyin from senior management, how do you set up the practice, and how do you govern your efforts. The philosophy seems very much to be that without creating the environment where an enterprise architecture effort can succeed, any discussion on metamodels and modelling techniques is moot. I have to admit to agreeing with this.

So which is better? TOGAF or PEAF? For me, the question is like asking which is better when cooking, having a kitchen or having the ingredients. They complement each other.

Selling a tool to your firefighters

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.

Showing the ROI of Enterprise Architecture

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…

Diagrams, not Wall Hangings

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.

Viewpoints in EA – “Cover Me!”

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.

Metadata: use it or ditch it

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…

BPMN: The difficulty is the benefit

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.

The importance of anecdotes

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.

  • Latest Comments

    Error parsing XSLT file: \xslt\BlogLatestComments.xslt