I keep being told how Digital Innovation and DevOps are going to save the world. Unfortunately for the salesmen I’ve been around long enough to have seen a magazine full of silver bullets, think Distributed Computing, PCs, Information Centers, Fourth Generation Languages, End User Computing, Object Orientation, ESBs, SOA, BPM and even Java to name a few. These were all going to solve all my problems. Mostly these ideas just moved things around a bit. Mostly money, it seems, from one bunch of share holders to another, and that while the names changed the problems basically didn’t.
Another observation I’ll make is, that when the latest wave of newbie techies get control of your IT agenda the the result is always the same. Business thinks my God these people are clever! Why can’t our IT guys be like them! Then there’s an initial excitement and burst of enthusiasm from the naive evangelists that belittles all that went before and stupefyingly simplifies anything they don’t understand. Which actually turns out to be rather a lot. Then after the frantic and often mindless pursuit of the latest shinny thing fails. Typically on same stupefyingly simple obstacle as the previous technology, the new technology with all its technical debt (remember that term?) is assimilated in to the legacy. The uber intelligent evangelists are off on the next cloud (no pun intended) and the executives responsible for moving all that money around sheepishly retreat into the woodwork leaving the clean up to the IT guys.
To speak plainly Enterprise Architecture has a poor reputation in many organizations and rightly so. One of the problems is that many EA programmes are stuck doing what I call EA2000; using ideas and concepts that were common about 2000. Indeed, many programmes are worse, practicing a degenerate form of EA2000 (Template2000) in which filling out documentation templates has been substituted for actually doing architecture.
So, rather than having to deal with EA programmes that simply aren’t fit for purpose and perhaps having learned from the past. But, more likely as an expediency to reduce over-site and allow the rivers of money to flow (usually out of the organization). We see the idea of two speed IT or Bimodal architecture rear there heads. The problem with these approaches is that they undermine the legitimacy of the EA programme. We’ve seen this before. The hose pipe cannot be serviced so some “guidelines” are put in place typically they say something like, projects under $100K don’t need architecture approval. Next thing you know every project is $99K! And the disasters flow unabated.
The correct response is to increase the capacity of the EA programme. Typically, this is interpreted as get more EAs. Something that’s just not going to get up in a lot of organizations. The other option, that I don’t see very often, is to make the EA programme more efficient. What that means is that the programme has to move beyond EA2000 and develop a methodology that is actually appropriate to the organization. It’s time to blend architecture and operations, even Zachman has a Function Enterprise perspective, with operations. It’s time to adapt, to create ArchOps and stop all this nonsense about architecture being old and slow.
Now, that sounds simple, but for a discipline that has no universally accepted body of knowledge and even struggles with concepts like definition it is not easy. But that’s why we like doing architecture. What’s more EAs have the advantage, they understand patterns, they have seen it all before. They are are the smartest guys in the room.
This is not your usual architecture book as its title suggests it is about modelling using the ArchiMate notation. The author doesn’t promote any particular tool and concentrates on the notation, which recently underwent a major revision.
Whether you are new to ArchiMate or have been using it for some time I think you’ll find this book useful. It starts with the foundational ideas of ArchiMate explaining the basic Elements and Relations: 3 x 3 x 3 rule. That’s the three rows of the meta-model, the Business and Information layer, the Application and Data and the Technology layers. These are subdivided into the Active Structure, the Behaviour and the Passive Structure. The trinity is completed by three types of relations Structural, Dynamic and “Other”. The discussion is accompanied by a multitude of concise examples and you could do a lot worse than drawing these examples up as you go along.
With the basics out of the way the text moves on to the more arcane elements like Interactions and Collaborations again providing lots of examples. With the core elements taken care of chapter three looks at Derived Relations and some pit falls for new players (Chapter 4).
Chapter six is all about style and patterns, the things that make the views easier to read. If you are new to modelling this is useful stuff, it’s the kinds of things that you’d rather not have to learn through your own mistakes. I’d suggest that you might even consider including some of the Anti-Patterns in your modelling standards.
The Advanced Subjects section is particularly interesting. Arguably, there is no right or wrong way of doing things, ArchiMate is a notation like English and there’s always someone who can write better than you. So, I’m interested in the ways that people choose to model particular scenarios and Wierda provides a couple of examples that I’ve never had to consider, data entry for example. But I must confess feeling a little let down by the section on ESBs. Given the prevalence of buses these days I think that his examples are frankly a bit laboured and perhaps a bit self indulgent. After all the purpose of modelling is to drive out ambiguity not obscure the issue in notation. I think this section is definitely a C –. I simply can’t believe that he couldn’t do better!
However, over all you have to give this work two thumbs up. If you’re modelling with ArchiMate get a copy. If you are not, get with the programme, buy a copy and start modelling.
Wierda, Gerben 2014, Mastering ArchiMate Edition II, P & A, The Netherlands
I have to declare my position. It will probably come as no surprise to those who read this site that I’m not exactly a fan of TOGAF. But, I have to say one of the best things they have ever done is support ArchiMate. I am a big fan of ArchiMate and use and promote it virtually every working day. So when I found out that a new version had been released I had to have it. So, in a way this is as much a review of ArchiMate than of the book.
If you don’t use the ArchiMate notation you need to get with the programme, anything else is like drawing in mud with a stick, messy and imprecise. First, a bit of a warning, there seems to have been a bit of a false start with version 2 of the specification and it seems that version 2 was short lived, perhaps only a few months. So, be warned there are still version 2.0 publications lurking around.
If you are familiar with ArchiMate I think you’ll be pleased with the new specification’s work on the language structure. Things have been clarified, aligned with the TOGAF crop circle and two new language extensions added, Implementation and Migration, and Motivation. Another, long overdue, and very useful addition is figure 59 on page 102. The Classification of Enterprise Architecture Viewpoints is a clever hexagonal model that identifies the use and target audiences of each viewpoint. Personally, I think this model should have featured much earlier in the work, but no matter at least its there and I think that new users in particular will find it useful.
As for the book, it’s soft back and I don’t think that’s a good idea for a working document. Mine is already showing the early signs of disintegration, despite considerable care being taken. Generally speaking the layout is clean and utilitarian and at less that 200 pages a pretty fair achievement. There are appropriately brief explanations of theoretically related topics like frameworks, which are useful for the novice in particular. But, I have to say that the book would look better if the text were aligned on both margins and I have come across the occasional odd sounding sentence. But, these are small asides.
If you are considering buying this book, and I really think all architects should, you’ll be interested to know that there is also a really useful Pocket Guide to ArchiMate, that I suspect may turn out to be more survivable, that you can get delivered to your door for about $25.
The Open Group, ArchiMate 2.1 Specification, The Open Group Series, Van Haren Publishing, Zaltbommel
While this book is not an architecture book, I’ve always maintained that architects need to be across the entire project delivery life cycle. So I think it’s relevant.
I’ll start with the book’s shortcomings, but don’t let them put you off, as it does have something to offer. To be frank, the style is a little rough, perhaps naive would be a better word, but there’s nothing here that a good copy editor couldn’t sort out. Personally, I’m not a fan of the “Dummies Guide” style of cartoons that the author uses, but they say a picture is worth a thousand words, and that’s perhaps particularly true when the writing’s not that good. Well, that’s enough bagging, and to miss-use another well worn saying, you shouldn’t judge a book by its cover. Or good ideas by their presentation.
This book is the very thoughtful work of, a clearly very bright person, who was thrown in the deep end. Placed in that unenviable position rather than just panicking, he embarked on a a crash course education in project management and the result is this book.
It’s clearly intended for people in similar circumstances and, when you accept that that is the origin of its shortcomings, it works very well. The author trots through the usual stuff, with an often surprising and refreshing combination of naivete and intelligent insight, and that’s what saves the book. It keeps throwing up little variations on the usual.
The author fearlessly tackles the tricky questions. Take for example, a question that stumps many experienced project managers. How do you reconcile the inclination to a waterfall view of the world, that project managers have, with an agile software development methodologies? While the book’ s views are sometimes a little unorthodox, they are typically thought through and well argued.
This is an ideal book for PMs just starting out and as a refresher for experienced PMs and Architects.
The book will undoubtedly, irritate some people, they shouldn’t buy it. But, I have to say that I bought and I think its worth its space on the book shelf. It’s a little, irreverent and a little disruptive, to the usual project management discourse and I like that.
Boyde, Joshua 2013, A Down to Earth Guide to SDLC Project Management
I’ve commented on the questionable ethics of some consultants previously, but something I witnessed recently prompts me to revisit the issue.
In the last three or so years in particular I suspect that I’ve witnessed, initially unnoticed, a growing tendency for consultancies to see clients’ projects increasingly in terms of cash flow and less as problems that need solutions. It seems that they care little about the outcome and obscure progress, or more often lack of it, with activity. They keep projects going even when they know they should red flag them just to keep the cash rolling in.
But recently, I’ve noticed a new twist to this game that impacts architects directly. One of the all time favorite architectural principles is “buy before you build”. It’s very simple reduce your risk and speed your delivery by buying COTS components where it makes sense. And making sense is a pretty simple arithmetic exercise. If you can buy it for the same or less than your build estimate then all things being equal you’re probably better off buying it.
Well, in one recent incident I’m aware of the architecture has been rejected because it wasn’t based on open source and so free software. This sudden conversion to open source turned out on examination, there was basically no open source equivalent, to be a curious choice.
After much wriggling and a number of long awkward silences the truth, as always, emerged. The consultants had factored the client’s entire budget in as services, which would naturally be carried out by them. And so when the architecture called for the purchase of some software they didn’t like that because the numbers were already in the forecast!
The lesson is clear. Set your principles and insist that your consultants explain if they deviate from them.
I am frequently appalled by the lack of rigor in this craft and this has been recently highlighted to me by a linguistic habit that I suspect comes from a younger generation. ( Sorry guys feel free to have a hack at the old bastard!)
That is the use of the answer Yes/No to a question. As I pointed out to one of our juniors Yes and No are binary. If architecture is about driving out ambiguity then this kind of answer is unacceptable. I suspect that this structure is the consequence of not wanting to convey information that might be construed as “bad news” to ones superiors or clients . If this is the case then the organization needs to take as serious look at the behavior of its leaders because they are responsible for this. They are suppressing information for their own comfort that ultimately the organization will pay for.
Answers, particularly architectural answers, are not about making the boss feel good. They are about logically and concisely passing on information. As the mediation gurus say it is neither good nor bad it just is. If you can’t handle that then you’re not leadership material and I suggest you get out of the way because things are hard enough without the irrational bullshit.
For those of you with an academic inclination I suggest looking up Jerry Luftman’s work. His work on alignments suggests a set of maturities that an organization must develop and guess what’s top of his list … communication!
Anyway, I’m going to finish off with a list of similar useless communicative structures and what they really signify. I wonder how many you’ve encountered this week? If you’ve got any favorites I’d like to hear them.
- Just …. As in just do this or that … I haven’t thought it through.
- All …. As in all you need to do is …. I haven’t thought it through.
- I think …. As in a response to how does this work? … I don’t know.
- Well basically … I don’t have a clue
- I’d like … I ‘m not sure what, but something like … I don’t have a clue
- I want … I want this or that … I don’t know what I need
- Oh! it works like that! …. I was bluffing before I don’t really know anything about it
- The specification could be interpreted in different ways … its not a specification or I haven’t actually read it and I was bluffing before.
- It’s in the design … As in how does this work? … Don’t ask me I was hoping someone else would figure it out!
First I have to declare that while I’ve never worked with Phil I have worked in the same organization and I do know him. So with any conflict of interest covered off we can now get down to business.
There are lots of books that will offer either directly or discursively a reference architecture. But typically these focus either a particular technology or problem domain. This book is different its focus is EA as it says in the early pages it is an aid to learning how to do EA.
Despite what the Open Group would have you believe there are many architectural methodologies around and in my humble opinion one of the best is Scott Bernard’s EA3 Framework. (Reviewed on this site).
One of the problems that confronts, particularly inexperienced architects, is tackling the chosen framework. What techniques need to be applied? Where should the effort be concentrated? And often, after not very long, why are we doing this bit? It’s about this time that having lost their way that projects typically reach crisis point.
What this book does is give you nine succinct sections, one for each layer of the model. Each section is an about twenty pages of good hard executable advice. Many of the questions could be and have been argued ad nauseam leading projects into the analysis paralysis that is the fate of so many projects. For example “Don’t labour on the shared enterprise and business services”, in two paragraphs the book puts the issue to bed and that’s typical of its no nonsense approach. One feature I like is that the Conclusion and Summary chapter is only one page.
Following the nine sections are a series of appendices that include an audit model, lists of questions and examples and some suggested reading. Unlike many appendix which are kind of the author’s bottom desk draw there is some real gold in these particularly for the new architect.
While this book is written with a particular methodology in mind and that in itself limits its applicability that should not be used as an excuse for ignoring it. This is a book for Enterprise Architects with a lot of hard won wisdom in it that will earn its place on your bookshelf. Highly recommended, for all sorts of reasons.
Woodworth, P.A. 2013, A Reference Architecture for Enterprise Architecture, Phil Woodworth, Sydney
Recently I’ve spent a lot of time investigating a system that’s been around for about ten years. Like many systems the developers are long gone and the system, ticking over reliably, has been ignored. Well its time to replace the system and also like many other similar systems no one actually knows what the thing does! As usual the documentation shows little sign of maintenance and inspires even less confidence. There’s only one thing for it, you have to go and read the code.
This proved to be more difficult than you can imagine. Besides there being no comments in the code, remember that old habit? At every turn every possible function had been abstracted sometimes three or four times. Component after component turned out to be little more than a container for the next level of function.
Don’t get me wrong I’m as keen on the separation of concerns as the next architect. But, in this case the result was a ridiculous ratio of functional code to packaging that simply made comprehension more difficult. Well I got to thinking about how this came about. The developers had plainly written the code for maximum reuse and extensibility, the problem was that ten years later none of it had been used and the resulting complexity and a lack of documentation made the system almost incomprehensible.
So the question must be asked when is it quality and when is it over engineering?
The other week, I’m being deliberately obtuse to spare some the embarrassment, I had to engage with a number of people, some in my organization others from outside.
What struck me was that everybody was an architect! But wait a minute I thought are they really?
The first architect I encountered was a Java architect. All he wanted to do was change my spec into the easiest possible code to write. That’s not very architectural. No he wasn’t an architect he was a developer I concluded.
The second architect I engaged goes under the title Enterprise Application Architect. Sounds pretty grand! Problem is I’ve known this guy for over twenty years. He has no technology foundation. He couldn’t program his micro wave. His entire career has been spent in management! He wasn’t even a particularly good project manager. He’s not an architect he’s a manager.
Anyway as the week progressed I was called on to hire an “architect” . Unfortunately, there was no shortage of applicants. But as I plowed through them I came to the conclusion that they were mostly developers, the odd project manager and a couple of escapees from the call center.
So it being Friday afternoon and me being exhausted by my fruitless search I thought I’d take a different tack. Like all good architects I’d concentrate on asking the right question.
The next applicant’s CV boldly declared he was an experienced architect. By this stage this was like a red flag to a bull.
My opening question was “Do you have any certification? Not that I’m convinced by that. “No” . “Have you been on any architecture training courses?”. “No”, was the slightly sheepish response. No surprises there.
“Okay, have you ever read a book on architecture?” I could see the poor guy was desperate to say yes to something. And for a moment I saw it in his eyes, but then he thought better of it as no doubt the possible follow up questions started to occur to him.” Actually no”.
“Do you actually have a business card that says architect?” Not that I’m impressed by that either. A very sheepish “No”.
Sensing blood, I honed in. ” So you have no training, no experience and you can’t even be bothered reading a book on architecture.” I paused for dramatic effect, after all it was Friday afternoon.
“So what makes you an architect?”
Well, that was it it he got up and left. I guess he wasn’t an architect.
Intangible value and Enterprise Architecture are two kindred topics. Accountants would have us believe that if you can’t value something it has no value. Which is kind of hypercritical when you consider that the biggest number on a balance sheet is usually depreciation and that’s a guess! Anyway if you find yourself in the predicament of having to assess the value of the seemingly unknowable then this book might just be the help you need.
There’s nothing radical in this book, you have probably seen it all before. But here it is all thoughtfully put together in a single volume with some telling questions, that need to be asked before you start measuring and topped off with a bit of method. I do like a good method.
The book consists of four sections Measurement, Before You Measure, Measurement Methods and Beyond the Basics which contain fourteen chapters in about 260 pages. The topics cover the purpose and meaning of measurement, the amount of measuring you should do, the type of measuring, risk, Monte Carlo simulation through to information economics.
I’m by no means an expert in this field, but then neither is the average architect. So I’d suggest that while this technically isn’t an architecture book it does cover a relevant and often tricky topic and so is a useful addition to the arsenal. Particularly if you get into one of those what’s the value of architecture bun fights.
Hubbard, Douglas W. 2007, How To Measure Anything Finding the Value of Intangibles in Business, John Wiley & Sons Inc, Hoboken, New Jersey