It’s NOT What it’s How that Matters

This is the third in a series of articles that decomposes some of the latest research into architecture in useful bite size pieces.

Thinking about giving up on the whole architecture deal, have a clean out and sack the whole lot and get some news ones in! Well before you do, there’s  some interesting new research that you should be aware of.

It’s been known for some time the failure rate for architecture programmes is exceptionally high; perhaps 95%. And that about 40% of all architecture programmes are cancelled very three years or so; with often unfortunate consequences for the Architects. We all know organizations that seem to be in an endless cycle of establish, frustrate and terminate.

Some organizations try to break the cycle by outsourcing the problem to consultancies. But, still nothing changes, except that now you have a smart looking set of metrics that tell you it’s still actually your problem! And by the way here’s this month’s bill.

If you were to scan the literature for answers you’d be forgiven for assuming that it’s all about method. That if somehow you could get a good enough ‘to-do list’ then you’d be home and hosed . Unfortunately, the research tells us that’s simply not the case.

The Failure of Success Factors (Hope, Chew & Sharma 2017) compares the performance of architecture programmes its purpose: empirically examining the core proposition of the CSF literature, viz. ‘that success of EA programmes is associated with the presence of certain CSFs while failure is associated with the absence of those CSFs’. This longitudinal research identified the presence of CSFs; drawn from over 500 literary observations, in particular programmes and compared their implementation against the outcomes of the programmes. In theory there should be a correlation between the factors and programme outcomes.

In a related piece of research 17 CSFs derived from the literature were assessed by over 200 Architects. Of those only five CSFs were identified by more than a third of Architects as critical with only two of those being assessed as such by more than half the Architects. Furthermore, only two of the five CSFs, Commitment to the Use of Architecture and Consultation and Communication also made a the top six of academically identified CSFs! Most of the CSFs were only rated as critical by around 20% – 30% of Architects with many technical CSFs in particular failing to impress even 20% of Architects.  Clearly, there is a gulf between academic sources and practicing Architects. But, the disconnect between practice, academia and management is a subject for another day!

Architect Identified Critical Success Factors
Factor
Critical %
Alignment with Business     68
Co-ordination with Developers
    37
Purpose of Architecture
   47
Commitment to the Use of Architecture   51
Consultation and Communication   74

The research also notes a disturbing tendency for anything that ‘sounds’ rigorous or objectively assessable to be marked down. ‘Formal methodologies, tools, quality control, maintenance and budgeting are all objectively assessable tasks. Curiously, for a discipline concerned with detail it seems that rigor is unwelcome’ (Hope 2015).

The Architects also seem to be gun shy when it comes to Monitoring for Compliance. Which makes the top six CSFs in the literature. But is in a some what trailing joint seventh place with Roles and Responsibilities barely ahead; and statistically not significantly, of the “also rans”.

The architects’ views about what is important don’t tally with the academic research.The data shows that the only factors significantly correlated with success were: Monitoring and Compliance; Commitment to the Use of Architecture and Consultation and Communication.

The use of methodologies, strategy and tools did not correlate with success. The conclusion: ‘this research empirically reinforces … The findings … that the methodological skills of architects need to be supplemented with process (or social) skills so that architects might be able to attend to key aspects of the organizational context to assure the success of EA programmes’.

As far back as Spewak and Hill a myth was born that ‘EAP should not be attempted in an unfavorable climate’ . Basically, that some organizations are unfit for EA. But, the Hope et al. research turns that proposition on its head suggesting that really it’s a matter of the architecture programmes not being fit for their organizations; and that performative adaptation is the key to architectural success.

So, what does this all mean? Basically we need a new approach and we’re not talking about more method or TOGAF certification or the latest tech fix. We’re talking about a whole new sociological centric paradigm, something that architects unfortunately aren’t typically familiar with or prepared for.

Purpose Driven Architecture Practice (PDAP) is the leading body of knowledge in this new space. If you haven’t heard of it, that’s not surprising the research was only published in late 2015. PDAP takes an empirically substantiate approach to the sociological aspects of architecture practice. Suggesting that architecture consists of three Architectonic Activities, whether you like it or not these activities, consisting of performative routines; told you it was different,  determine the programme’s fate.

If you’d like to know more about PDAP then email PraXtice@TrueTechnologyPartners.com.au True Technology Partners are the only organization in Australia qualified in PDAP.

No Comments

Architects Don’t Know What They’re Doing!

This is the second in a series of articles that decomposes some of the latest research into architecture in useful bite size pieces.

It’s official, Architects are trained all wrong and that goes a long way to explaining why so many programmes end up in trouble. Whether you take Zachman’s 1987 paper as the start of the architectural time-line or not, doesn’t really matter. The point stands that architecture, as in the planning of IT systems, has now been around for thirty years. So why do we still struggle with it? Why is it that only 5% of organizations are able to effectively leverage architecture?

It has long been recognized that architecture lacks basic research. ‘Although a wide range of topics is covered, the discipline is lacking basic research.’ (Langenberg & Wegmann 2004) ‘enterprise architecture is a new discipline and it will not mature unless substantial basic research will be made’.(Noran 2003).

Well it seems that some of that ‘basic research’ has finally been done (Hope 2015 ) and some of the results are a bit disturbing. Like the fact that Architects basically aren’t prepared for their role. Then it’s hardly surprising that they don’t know what they are doing (See 30 years and we don’t know what we are doing).

Furthermore, the architects’ beliefs just don’t tally with the academic research.The analysis shows that the only factors significantly correlated with the success of an architecture programme are Monitoring and Compliance, Commitment to the Use of Architecture, Consultation and Communication. The widely held views that methodologies, strategy and tools were the keys to success simply isn’t true.

Hundreds of Architects were surveyed about their training and asked to classify its effectiveness based on the skills required to cover off a number of potential critical success factors identified by the research.. They were also asked about their formal education. And here’s what they said:

Qualifications
Highest Qualification %
High School     5%
Bachelor’s Degree   35%
Master’s Degree   40%
Doctorate     7%

As a group Architects are reasonably well educated, should have a degree and probably should be looking at a masters even if it is just to be keeping up. But the really interesting information is about the vocational training.

Skills and Training
Skill None None/Poor Poor/Adhoc Competent Better
Project Management   30%      
SDLC     26%    
Testing     54%    
Requirements Gathering 32%     49%  
Data Analysis 39%   19%    
Architecture Methodology   37%     45%
Problem Solving 34%   12%    
Business Theory 33%   17%    
Technical Writing 39%   17%    
Interpersonal Communication         75%

Overall the architects’ background did not seem to influence the training they received. And they were least likely to claim Excellent training in Testing, Data Analysis and Technical Writing.

So, what does this all mean? Basically vocational education seems largely absent. And when it does occur it recognizes two things methodology and the importance of communication. The problem with the emphasis on methodological training is that the research shows that the actual method used is a lot less important than the practice used to implement it. (Hope, Chew & Sharma 2017 The Failure of Success Factors)

As for the concentration communication training, it looks a lot like the desperate last resort of organizations, that don’t invest in their Architects; a vain attempt to fix the glaringly obvious. However, it’s clearly not working!

We’re talking about a failed methodological paradigm! What’s needed is an alternative that gets to grips with the real issues. Purpose Driven Architecture Practice (PDAP) offers such a new paradigm. If you haven’t heard of it, that’s not surprising the research was only published in late 2015. PDAP takes an empirically substantiate approach to architecture practice to develop a socio-centric approach. Suggesting that architecture consists of three Architectonic Activities, whether you like it or not these activities are going on all the time and they determine the fate of the architecture programme.

If you’d like to know more about PDAP then email PraXtice@TrueTechnologyPartners.com.au True Technology Partners are the only organization in Australia qualified in PDAP.

No Comments

Thirty Years and We Still Do NOT Know What We are Doing!

This is the first in a series of articles that will bring the latest research into architecture to you in useful bit size pieces.

Whether you take Zachman’s 1987 paper as the start of the architectural time-line or not doesn’t really matter. The point stands that architecture, as in the planning of IT systems, has now been around for thirty years. And so why do people still refer to it as emergent? It’s because although we may know what a good architecture programme looks like we still struggle to know how to achieve it. How is it that after all this time there’s still a different definition of architecture for every book written on it; well almost! I guess it comes down to knowing what architecture is. If we knew that we could sort out its epistemology. We might actually have a chance of deciding what matters and what doesn’t. In short we could identify its Critical Success Factors (CSF). It has long been recognized that architecture lacks this kind of basic research. ‘Although a wide range of topics is covered, the discipline is lacking basic research.’ (Langenberg and Wegmann 2004 Enterprise Architecture: What Aspects is Current Research Targeting?) ‘enterprise architecture is a new discipline and it will not mature unless substantial basic research will be made’.(Noran 2003).

Well some of that ‘basic research’ has finally been done (Hope 2015 The Critical Success Factors of Enterprise Architecture). And some of the results are to say the least a bit disturbing. Like the fact that given a choice of CSFs drawn from the literature a college of over 200 Architects basically can’t tell you what the CSFs are. In fact, they can barely differentiate the critical from the merely important. Even then they are a lot further from consensus than you’d expect or like.

Architects were asked to rate the importance CSFs on a scale of 1 to 5 with 1 being Not Important and 5 Critically Important. Most CSFs were rated 3 or higher by 85% of the respondents. This situation is exasperated when it is revealed that ‘bogus’ CSFs rated as highly as the genuine ones. When filtered for ‘critical’ only you finally get some insight. Just for the record they were: Alignment with Business 68%, Coordination with Developers 37%,Purpose of Architecture 47%, Commitment to the Use of Architecture 51% and Consultation and Communication 74%

But the results are particularly comforting when you realize that out of 25 CSFs only five were picked by more than a third of Architects and only two by seriously more than half the respondents. The research also notes a disturbing tendency for anything that ‘sounds’ rigorous or objectively assessable to be marked down. ‘Formal methodologies, tools, quality control, maintenance and budgeting are all objectively assessable tasks. Curiously, for a discipline concerned with detail it seems that rigor is unwelcome’ (Hope 2015).

Furthermore, the architects’ choices don’t tally with the academic research.

Academic CSFs
Critical Success Factor Critical %
Use of Formal Methodology    63
Use of Tools    25
Strategy for the Development of Architecture    33
Monitoring & Compliance    30
Commitment to the Use of Architecture    42
Consultation and Communication    51

Arguably this data is just as indecisive as the survey data and is possibly biased by the methodological bent of the literature. Could it be that we can’t get consensus because we’re not asking the right questions? It seems that the classical empirical approach to this problem has failed. That failure is underlined, perhaps ironically, by the survey responses to questions about how well the architects thought they executed against the CSFs. ‘Only two CSFs were considered to have been excellently executed and only by around 10% of respondents. These are Alignment with the Business at 11%, considered critical by 68% and Understanding the AS-IS State with 10%, considered critical by 33% of respondents. Consultation and Communication, considered critical by 74% of respondents, scores only 8%.’

So, what does this all mean? Basically neither the academics nor the practitioners know what matters and it seems that perhaps many things may be important in different ways. That there is no ‘golden’ to-do list, no TOGAF like body of knowledge is going to save us. We’re talking about the need for an alternative paradigm, something that Architects unfortunately aren’t typically familiar with. Purpose Driven Architecture Practice (PDAP) offers such a new paradigm. If you haven’t heard of it, that’s not surprising the research was only published in late 2015. PDAP takes an empirically substantiate approach to architecture practice to develop a socio-centric approach. Suggesting that architecture consists of three Architectonic Activities, whether you like it or not these activities are going on all the time and they determine the fate of the programme.

For more information about PDAP or PraXtice email PraXtice@Truetechnologypartners.com.au

No Comments

PraXtice Available for Xmas!

It’s been almost a year since we noted the arrival of PraXtice the first “ready to use out of the box” architecture methodology.  And we are now happy to report that it’s available through both Amazon and Google books just in time for Christmas. So, why not treat yourself and get ready to start next year by taking your architecture to a whole new level!

Free PraXtice 2017 is now available from Amazon Kindle and Google Play.

https://www.amazon.com.au/Free-PraXtice-2017-Technology-Partners-ebook/dp/B077SHYJ1L/ref=sr_1_1?s=digital-text&ie=UTF8&qid=1513063615&sr=1-1&keywords=free+praxtice

https://play.google.com/store/books/details/Dr_Thomas_Hope_Free_PraXtice_2017?id=H8lBDwAAQBAJ

The model is available from:

https://truetechnologypartners.com.au/

Highly recommended!

Enjoy!

Ho! Ho! Ho! Happy PraXmas!

No Comments

Everybody Needs PraXtice

This year marks thirty years since the publishing of Zachman’s seminal paper. And since then there’s been a torrent of publications on architecture. What’s always puzzled me was that despite all that brain power and all that paper, and believe me I’ve got bookcases and filing cabinets full of it, I’ve never come across  a lightweight fit for purpose architecture methodology. Well that was until now! PraXtice from True Technology Partners is exactly what Architects have been hanging out for. It’s been a log time coming!

In its simple direct style “PraXtice is a research based methodology designed for Architects by Architects. The goal is a methodology that shows you HOW, not simply tells you WHAT to do.” It does what it says with no apologies,   its intent is clear and concise. “Our objective with PraXtice is to provide a practical methodology that you can start using today and to get you going as quickly as possible.” And it does that in about 16 pages!

Before we all get carried away PraXtice makes it clear in its unequivocal style, in what may be the best paragraph ever written about architecture, that there is more to architecture than the mere application of methodology or the completion of a template.  The Crystal Clear Statement, the second paragraph of the documents says it all:

“Let us make one thing CRYSTAL CLEAR right from the outset. PraXtice is a tool for Architects. Applying PraXtice might improve your architecture practice, but it will NOT make you an Architect. There is more to architecture than any methodology can provide. The folks at True Technology Partners know that it takes a long time, patience and a lot of effort to become an Architect. The PraXtice methodologies assume that you have served your apprenticeship and that you have the prerequisite knowledge and experience and access to the necessary resources and artefacts. If you think you can Google your way through this one; you are very much mistaken!”

You just have to love the clarity! PraXtice comes in four versions Free, Professional, Complete and Advanced. And get this Free is exactly that, you can download it or copy it and give it to your friends or not. As the TTP folks say where’s the risk? What’s more, in this over hyped commercialized world, you’d never guess that you can’t just get the cheque book out and buy Advanced edition, your organization has to qualify for it! How’s that?

The production values on PraXtice may be a bit on the light side, but it’s the content that counts. And as they say never judge a book by its cover.

Access to PraXtice is a little limited at the moment, but if you email PraXtice@truetechnologypartners.com.au the folks there are really helpful. Give it a go, it’s probably better than what you’re doing now. And what have you got to lose?

 

The Archi Tool  http://www.archimatetool.com/download

No Comments

ArchOps

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.

No Comments

Mastering ArchiMate

Wierda

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
ISBN: 978-90-819840-4-1

3 Comments

ArchiMate 2.1 Specifiction

 

TOGAF

 

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.

Highly recommended.

The Open Group,  ArchiMate 2.1 Specification, The Open Group Series, Van Haren Publishing, Zaltbommel

2 Comments

A Down to Earth Guide to SDLC Project Management

DowntoEarth

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

 

No Comments

$harp Practice

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.

No Comments