Bias, Process and Credibility

February 13th, 2010

I’ll start by posing a question. What is the most important attribute of an architect? What is it that makes him effective?

Is it technical skill, experience, communications skills? I’d suggest that it is credibility. Where does this come from, obviously it can have it’s foundation in any of the skills noted above and probably many more that I’ve not mentioned. However, I’d argue that ultimately, credibility is about trust. It’s about people trusting the architect. Trusting that he’s telling the truth and that he is giving them as accurate and impartial assessment of the topic as is possible for a mere mortal.

Impartiality is an important lesson that too few architects seem to have learned. Architecture is not about who’s right it’s about what’s right for the client. One way that we ensure impartiality is by having objective processes that minimize individual bias  and provide transparency for decisions. By no means are any of these processes perfect, traceability makes the process transparent and so when someone is unhappy with the decision the reasoning behind it can be explained. By this means a good architect protects his client’s interests  and indirectly his greatest asset his own credibility.

I’ll give you an example. Recently a technically competent, but frankly rather arrogant architect at a client of mine made a “judgment” call. Without consulting the rest of his practice or recording his process. This resulted in him  excluding a particular vendor from a selection process for a pretty much commoditized capability. His reason he’d seen the product “years ago and it wasn’t that good then. I doubt it would have changed..” he went on “besides I don’t like XXXXXX”.

The problem with this is he’s lazy he’s made a call based on information that he admits is old and hasn’t  given XXXXXX a chance to change his mind. This isn’t what your boss pays for when he hires you. This architect has no doubt done this many times and because his client trusts him he can get away without due process, he is abusing their trust.

This particular architect however has come unstuck. The vendor unhappy with the unfairness of the decision has forced a meeting with higher management and because the architect has been  lazy and not a little bit arrogant he has no defense. There is no recorded assessment process, no defined principles, just his say so. He’s looking pretty vulnerable right now, his management are more than a little embarrassed and have insisted that a proper assessment be done. Architecture is about rigor, being told by executives that you haven’t been rigorous enough should be a humiliation for an architect.  Now I wouldn’t be surprised if this guy fixes the assessment process so that the vendor can’t win, because for him it’s about him being right. But, the fool doesn’t seem to realize that the real damage has been done. From now on every decision he makes will be questioned by his executive because he was lazy,  biased and has betrayed their trust.  He’s credibility is now shot.

Truth and consequences a cautionary tale for architects

February 7th, 2010

Once upon a time there was an architect known to his friends as Elmo, who worked for a very large cowardly, cheapskate outsourcer. One of this outsourcer’s clients was an even bigger and meaner bank.

One day the even bigger meaner bank who were in the habit of bullying the very large cowardly, cheapskate outsourcer decided that they needed a disaster recover drill. Actually, being a big mean bank they really couldn’t care less, but the one thing they sought of feared, a slow moving  almost toothless regulator was on the prowl. And given how banks had recently almost ended the world as most us know it, they were almost sensitive to the idea of what people might think and were affraid that the slow moving almost toothless usually ineffective regulator might actually bite them as they too were being scrutinized because of the recent near death experience of the world economy was seen by not a few people as being at least partly their responsibility. So a scenario of the cheap, mean, cowardly, unwillling and usually ineffectual came to pass. All things being equal there were no great expectations.

Elmo the architect was assigned to certify that this drill was effective. Which all sounds very professional. But is really the big mean bank’s way of mitigating risk, of passing the risk to the people best able to handle it. Which is short hand for any barely credible idiot greedy and dumb enough to take it! After all the one thing the recent near death experience of the world economy had demonstrated was just how good banks were at managing risk and what good fellows they were when it came to accepting responsibility and the tax payer’s money.

Anyway, Elmo’s a pretty good architect, a diligent keeper of notes and he knows a thing or two about this kind of drill. A real contrast to the usual half arsed preparation done by the  very large cowardly, cheapskate outsourcer. While this sounds good and I’m sure the large cowardly cheapskate outsourcer exploits Elmo’s diligence for marketing purposes to win business, his rigor really isn’t part of their business plan. The appearance of it is, but not the actual detail, after all who really cares? Well, Elmo cared because Elmo had certain values another area that the recent near death experience of the world economy had exposed as a strength of the banks and the finance industry in general.

So, on the night of the drill, Elmo in attendance observes carefully, taking notes, lots of notes, lots of good notes with time stamps. At the end of the drill the certification decision isn’t difficult, because Elmo had taken notes, lots of notes, good notes with time stamps. “No chance” he says! And referring to his notes, his good notes he reals of f reason after reason way the drill failed to the very large cowardly, cheapskate outsourcer’s account team and goes home to sleep with a clear conscious. He’d done his job and it wasn’t his problem to fix. The account team will have to talk to the big mean bank. It was  going to take some money to fix these issues.

The very large, cowardly cheapskate outsourcer’s account team have been bullied so often by the he big mean bank that the mere thought of doing anything other than genuflecting to the bank’s very whim  provokes a panic attack! What’s worse they know so little about IT  that they can’t actually explain to the always grumpy big mean bank what needs to be done. This made the big mean bank even angrier than usual and the very large cowardly, cheapskate outsourcer’s account team responded by being even more pathetic than usual.

So, filled with fear and unable to explain themselves the very large cowardly, cheapskate outsourcer’s account team resorts to the only behavior it knows works. Why not, it works on them; they start trying to bully Elmo. At first this was a low level cowardly bullying; as you might expect, which Elmo, being an easy going kind of architect  just takes as folks under pressure being a little snappy. But, he doesn’t change his position. No certification for all these reasons. Well, the very large, cowardly cheapskate outsourcer’s account team are a gasp a techie talking back to them! Well they weren’t sure if he was or not because he kept using words they don’t understand. But, it can’t be good because he won’t say yes. And this was really bad because it meant that the big mean bank would shout at them again and be very unhappy and they might have to spend some money and bring down the profit on the account which would make the boss of the very large cowardly, cheapskate outsourcer  also shout and not give them some money, they might even miss a payment on their Porsches.

There’s nothing for it the problem must be addressed they decided with remarkable determination for a team that generally only genuflects. We’ll take this problem by the horns! The architect must change his assessment. Then the big mean bank will be happy and we we’ll make our Porsche payments and all will be well.

Problem was Elmo had values one of those was professionalism, increasingly rare I know and often a liability, but believe me highly desirable.  Well you can imagine the sought of thing that went on as the increasingly hysterical very large cowardly, cheapskate outsourcer’s account team tried the “truth as a social construct” approach on the positivist objectivist  trained architect. True to his word Elmo could not be convinced, after all he had the notes, lots of notes, really good notes with time stamps.

So, very large cowardly, cheapskate outsourcer’s account team waited until Elmo went on leave and convinced some other architect; who hadn’t been present at the drill and had no notes, of the utility of socially constructed alternative realities and all was well. The big mean bank stopped shouting and they could make their Porsche payments.

And they all would have all lived happily ever after if it were not for the slow moving almost toothless usually ineffective regulator actually catching up with the game! See how it doesn’t happen until the last chapter. Now they also kept notes, really good notes with date stamps. And one of these notes said that last time this drill was done it wasn’t that flash and what’s more you the big mean bank better make sure that the very large cowardly, cheapskate outsourcer tests this stuff more thoroughly next time to prove you are taking us seriously or else we’ll bite you!

Well, the big mean bank is insisting that the  very large cowardly, cheapskate outsourcer should take the slow moving almost toothless usually ineffective regulator bite on its behalf as they certified the drill! Meanwhile the very large cowardly, cheapskate outsourcer’s account team are all polishing their Porches  and looking the other way while the certifying architect is polishing his CV. The slow moving almost toothless usually ineffective regulator is impatiently tapping its feet and polishing its teeth. The only one who sleeps soundly is Elmo.

Moral of the story, keep notes, lots of notes with timestamps and don’t give in to the wankers in the suits.

I/T Architecture in Action

January 8th, 2010

This book is about IT Architecture and is a methodology based on a technical five domain framework; Applications, Information, Network, Platform and Operations. It addresses each providing pretty much the currently accepted practices for each domain.

This means that over time the book will probably not age that well, but it is a fairly sound summary of the current state of play. It includes areas and concepts like wireless, ESBs, ODS and even SOA and virtualization, in a concise but not very detailed way.  After all it is only 180 pages and there would be books with more  pages on every one of these topics.

The  philosophy of  blending  “strict rigor and organic innovation”  sets this book a little at odds with the Euro architects, but it does produce an easy reading and informative text.  The book opens with the all too common Why EA? sell chapter;  in which he covers off the usual agility verses cohesion issues.  However, I think it is in the next two chapters on Architectural Principles and Governance in which the book makes its real contribution.

Principles seem to be a problem for a lot of architects. Particularly, connecting them in a meaningful way to the design and development domains. This book offers what may be the best twenty odd pages linking business models and strategy to principles that I’ve seen written for the layman.  He goes on to back this up with a simple, but better than average chapter on governance.  In which he rather timidly pokes a stick at the “managerial behavior” elephant. I can almost feel him constraining his frustration to the suggestion of a few metrics for the architectural review board’s performance. Unfortunately, he doesn’t have much to say about handling architectural exceptions, but then again not many authors do.

This is a good book, current, and easily read,  a little lightweight and while some sections will with time become obsolete others contain sound advice obviously born of experience.  Not deeply technical or academic it is a more than a fair attempt to bridge the business IT divide. I think most architects would find something useful in this book.

Reese, Richard J. (2008), I/T Architecture in Action, Tyler Westcott

ISBN 978-1- 4363-0505-1



Religious Wars and One Trick Ponies

December 29th, 2009

You used to hear the phrase all the time “oh that’s a religious war” it would be Microsoft verses IBM or Tibco verses MQ. Or any other groups of bigots at loggerheads, each defending their turf for little other reason than that they could. In recent times the religious wars seemed to have subsided perhaps the term is now considered politically incorrect or perhaps the affairs of a dangerous world have made us pick our words more cautiously.

Anyway, what’s this all got to do with architecture you might ask? We’ll I contend and I know I’m not alone in this that the quality of architects is a real issue for the discipline. As I’ve said on many occasions every man and his dog has the title these days and most of them are not worth feeding. The religious wars which at least required the expenditure of energy and some intellectual effort have been replaced by organizations dominated by one trick ponies. These are architects often with fine technical pedigrees that have fallen for a golden hammer pattern. No prizes for guessing which pattern that is.

I’ll give you an example, recently looking at a client’s issue the obvious and most cost effective answer was to exploit their existing mainframe. However, the consultants had recommended a Unix solution. So, being the sort of architect that likes to know why I asked. The consultant’s indignant answer was “least risk”. Okay, I thought sounds good. Problem was it wasn’t true; least ways not from the client’s perspective, they had no Unix skills and a battery of mainframers. So, being the sort of architect that likes to know why I pressed the point. The by now, decidedly defensive consultant caved and admitted that the decision was made to reduce their risk; they had no mainframe skills. They were one trick ponies. They didn’t have an opinion they had an answer, but only one and it didn’t matter what the question was! And this was a VERY big consultancy, the sort of brand that you would expect more from, well at least an honest opinion.

Now while I look down on these people, because lets be blunt they are lying in an attempt to secure a project that they aren’t qualified for based on the hope that they can somehow pull it off. (A dazzling example of managing risk … upwards!) Why people do this I’ll never know it ALWAYS ends in tears. But I guess it keeps the cash flow going for a while. I can at least understand the consultant’s commercial predicament which should stand as a warning to all those that employ consultants. I guess the law of inverse competency should be applied when hiring consultants, even from VERY big consultancies.

What I find a little harder to understand is when the internal architects behave in willfully ignorant ways. At another client I encountered a newly appointed senior architect who gleefully informed me that he was mainframe ignorant, which was kind of interesting that he’d got the job as that platform was basically the business. So, being the sort of architect that likes to know why I asked if he intended to correct the obviously shortcoming? “Oh no that won’t be necessary, the mainframe will be replaced.” That all went well until he met the LU6.2 APPC application. Shortly there after, and several million dollars later both the architect and the mainframe were replaced one by a new architect and the other by a new mainframe. That’s beside the point.

And we wonder why executives won’t take architects seriously. Well its because far too few architects take architecture seriously. In many organizations architect is just another classification for a technologist. The consequences are technology based religious wars and an epidemic of one trick ponies running around with their golden hammers! Typically, this behavior is reinforced by architecture practices that clone their architects. They are all the same! I guess it cuts down on the religious wars when every one thinks the same, but it’s REALLY bad architecture. The wars have been replaced with equally evil and mindless theocracies.  No wonder TOGAF is making such head way! Architecture is about what’s right NOT who’s right. A lot of architects need to grow up and take their responsibilities seriously.

Real Enterprise Architecture

December 22nd, 2009

Graves

This book really is about Enterprise Architecture with the emphasis on the enterprise and not the IT architecture. Written by a frustrated practitioner it offers a cohesive while perhaps not as comprehensive as one might like methodology in a very compact 130 + pages including glossary.

The book starts with devastatingly simple proposition that “Enterprise-architecture is the integration of everything the enterprise is and does.” It works for me. The first chapter establishes the methods framework a twenty five cell structure that maps Purpose, People, Preparation, Process and Performance drawn from a project management methodology against five “sideways views”. These are Efficient, Reliable, Elegant, Appropriate and Integrated. While I kind of get the 5 Ps I kind of missed the “sideways views”. I mean Elegant?

The lack of a foundational theory and the immediate progression to a framework is a little alarming particularly when the rest of the book is then dedicated to filling out the framework. Twenty five cells in about 120 pages (less than five pages a cell) with I must say a reasonable amount of white space at the end of many of the sections. Not surprisingly, there is not much meat to the tools and techniques used to fill out the cells.

Given its size this volume was never going to be much more than a set of architect’s notes. But putting that aside and being impressed with it not giving into the temptation of becoming an IT architecture book, I have to be positive about this book. Small, concise and perhaps a little overawed by the concept of recursion this book tackles EA without falling for the IT trap.

This is a book as it says itself for chief officers, strategists and programme managers and I agree with that. This is not the book to start your collection with and probably isn’t that much use to the average IT focused corporate architect. And frankly it’s a bit pricey for what it is. But, is it worth a slot in your EA library? I’d have to give it a reserved yes. Not wishing to damn it with faint praise, it is what it is.

Graves, Tom (2008), Real Enterprise Architecture, Tetradian Books, Colchester

ISBN 978-1-906681-00-5

Beyond Software Architecture

December 20th, 2009

Hohman

Initially you’d have to question reviewing this book as an EA book at all; although some enterprise architects need to be reminded that ultimately EA is about software. This book is really aimed at software developers who want to market a product, in the authors own words, “single-user programs costing less than $50″. I’ve not read much in this space so I’m not that good a judge, but its seems a competent work to me.

Hohmann’s developers are not the typical corporate IT department software developers encountered in architecture books. But, here’s the EA angle, there are lessons to be learned from this market driven software development viewpoint.

Hohmann’s search for a winning solution constantly connects his software development strategy to business imperatives and it is this search for a greater context that makes this book worth a look. His thoughts on the forces that shape software architecture, “marketecture”, market maturity, usability, training, education, user communities, product releases, upgrading and patch management are as valid for an internal corporate audience as they are for the open market.

Not surprisingly the book spends some effort on the commercial issues of COTS software like licensing and business models which might help you understand your vendors better, but won’t be of much use to the average corporate architect.

This book is for small scale software developers who want to produce software that resonates with their target market. This is not an EA book, but having said that I’m of the firm belief that no one has a mortage on good ideas and that a good architect reads eclectically. So if you are involved with developing software either within your organization or for the general market then borrow a friends copy for the weekend.

Hohmann, Luke (2004) Beyond Software Architecture, Signature Series, Addison-Wesley, Boston

ISBN 0-20-177594-8

Enterprise Architecture

December 14th, 2009

Johnson

This is an interesting book. In a curious way it is almost devoid of an underlying theory, something I’ve criticized many methods and books for and yet it maintains a cohesion that is difficult to fault.

This book is about models, decision and analysis techniques and that makes it quite a rare and useful volume. I am frequently dismayed by the poor analytical skills of architects that I encounter day to day. This book has the analysis process and its management as its central theme and manages to do it without becoming overly academic which is a bit of a triumph.

Think EA meets operations research and you’ll start to get a feel for a book dedicated to rational (no not the IBM brand) enterprise information systems management. This is EA as decision support for the CIO.

It discusses strategic issues like goal setting and decision alternatives and domain definition. It then takes these goals and breaks them down into properties and provides techniques for collecting evidence; a practice that isn’t as well developed as one would expect in many organizations.

The authors support this approach with a huge number of simple, but thought provoking models just the kind of thing you need to get you working on your problems. My favorite is the credibility of evidence model. There’s a section on intuitive EA assessment in which they manage to give the process a lot more structure and logic than the usual rubbish that passes for intuitive analysis. And the section on organizing for EA actually has more content than is apparent on first inspection. But you’ll have to work your way through the models. Based on COBIT the EA as a process approach reminds me a lot of Spewak and Hill with the same directness and perhaps a similar failing to grapple with social realities.

The book only credits two authors on the cover however I counted about adozen contributors. The writting is clear concise if somewhat bland typical “Euro Architecture” style, but at 300 pages not too hard a read. This is not the book to base your practice on, it’s not strong on governance or business integration. However, it is one of the best technique books you’ll find. This is the sort of book that you’ll reference more than read. Not a book for beginners or managers but obviously worth its place on your bookshelf.

Johnson, Pontus and Ekstedt Mathias (2007), Enterprise Architecture, Studentlitteratur AB, Lund,  Sweden

ISBN 978-91-44-02752-4

Enterprise Architecture

December 6th, 2009

optland

This is a small book with big ambitions. At only a little over 140 pages it is by EA standards a modest volume. But that shouldn’t put you off.

The book presents a surprisingly comprehensive approach to EA with a simple and yet well structured theoretical foundation and enough practical detail to make it credible without overwhelming the novice.

Written as a text book for an architectural course it consists of four main sections. These include the usual explanation for why we need EA, updated for the global economy and a little more stakeholder centric than the usual effort. Followed by “positioning EA” which is actually more like defining and describing EA and then two sections on the execution of EA.

One of these is the now a days almost obligatory case study / example, typically the refuge of people who can’t actually explain what they mean. My initial reaction was to reach for the phone, order a pizza and turn on the football. But, surprisingly the situation was saved by an example with some real meat.  Not only do the authors demonstrate their points, but they manage to connect them to both their own technique and broader well know concepts like Zachman’s framework; all without becoming arcane. In 30 odd pages they deliver more value for the architect than many complete books.

They follow these sections up with a topic that should be getting more air play than it is “The Enterprise Architect”. It seems that these days every man and his dog is an architect, frankly I wouldn’t feed many of them. But, having said that it’s no easy matter deciding what makes an architect. Well, this book has a good go at answering that question and even if you don’t agree with the them  there is a certain order and cohesion to their argument that must be respected.

This is a crisp clean work written in “Euro Architecture” style, which is not surprising given its origins. It will work for architects at all levels and will add value to any bookshelf.  Recommended.

Opt’land, Martin, Proper, Erik, Waage, Maarten, Cleo, Jeroen, Steghuis, Claidia 2009, “Enterprise Architecture”, Springer-Verlag Berlin Heidelberg

ISBN 978-3-540-85232-2

An Enterprise Architecture Development Framework 3rd Edition

October 24th, 2009

Grigoriu2FrontCover

I don’t like buying the same thing twice. On first inspection one might think that was what one was doing. This new edition of a book we’ve already reviewed will look familiar to those who have the previous volume; even the number of pages in each section is similar.

I’m also suspicious of later releases that are substantially bigger than the original work; the previous edition weighs in at 220+ pages while this work has stacked on another 130 pages. Which you would think is a bit of a warning sign, but it wears it surprisingly well. I didn’t feel like it was that much of an imposition. In fact, its a feature of the book how already succinct sections have actually been trimmed even further allowing more room for the expansion of the important stuff.

While maintaining the orientation of the original work Grigoriu has addressed the short comings of the previous edition. His framework is now much more securely seated in the foundations of Zachman and Spewak without losing that business process and organizational focus that made the original work  stand out.  Something that’s not easy to achieve.

While the book takes a cursory look at the usual framework suspects it does so mainly to establish its own credentials. The bulk of the new material is not surprisingly an elaboration of Function, Flow Layer and Views (FFLV) Framework and the result is coming of age, a framework that can punch it out with the best of them! The bar has been raised and if you’re not one of the TOGAF mind slaves the FFLV has to be a serious contender. Accept its business process focus and use something else for the more abstract end of business strategy, but for the mechanics of execution this could be it.

I think it’s fair to say that this is the book that Grigoriu always wanted to write and that its production has been a bit of a journey, but the best things always take time. I criticized the previous edition for not being as complete as it should have been, well that’s been answered and while nothing is ever perfect I found myself thinking I’ve got to get a copy of this!

This is not a book for managers. This is a book for architects. It’s a good set of alternative views in an alarmingly increasingly monoclonal world. This book will extend most architects’ horizons, experienced or novice and is a worthy successor to the previous edition. It’s time to upgrade your library. This could be the “little black book of EA”.

Grigoriu, Adrian (2009), An Enterprise Architecture Development Framework 3rd Edition , Trafford Publishing, Victoria, British Columbia.

ISBN 141208665-5

TOGAF The Open Group Architecture Framework 100 Success Secrets

October 6th, 2009

RaynardFront

When you read a book where do you start? I always start at the back, the back cover to be precise. There was a certain familiar ring to what I read on this occasion. See if you can pick it? “There has never been a TOGAF Guide like this. 100 Success Secrets is not about the ins and outs of TOGAF. Instead, it answers the top 100 questions that we were asked and those we came across in forums, …”

Almost instantly I dived for my copy of Enterprise Architecture 100 Success Secrets, and there on the back cover it was. “There has never been an Enterprise Architecture manual like this. 100 Success Secrets is not about the ins and outs of Enterprise Architecture.” At this point they removed a blank line to make it a little less obvious and continued. “Instead, it answers the top 100 questions that we were asked and those we came across in forums, …”

Same author I thought, Gerard Blokdijk and Boyce Raynard, apparently not. Same publisher I thought, hard to tell, I couldn’t find the accreditation. I’d suggest that one of these gentlemen should be acknowledging the other or that possibly they are the same person. But, I don’t know why one might expect that from someone with such a cavalier attitude to IP and copyright. Interestingly, page 11 in both volumes is blank, same manuscript perhaps?

I’ve had my say about EA 100 Sucks Secrets and it applies equally to this con job. With one addition, typically I don’t like to criticize the quality of language in a book, after all many works are translated and many of the best EA writers are not native English speakers. Besides its banal content, this is without doubt the most appallingly written EA book I have come across. I’m left with the distinct impression that it was written by someone whose command of English leaves something to be desired, like someone else to do the writing. Grammatically challenged and logically incoherent. I suspect each topic is restricted to about a page to limit the amount of damage it can do.

I could go on about why would one have a section on Enterprise Architect 6.1, 6.5 and 7.0 as well as sections about downloading it?  Or ask why is there a section dedicated to the difference between a CV and a Resume?  But,  I can’t be bothered shredding this rubbish.  But, that’s just my opinion.

At this point I usually give the ISBN and publisher details, but it’s really not worth the effort.