Archive for category Uncategorized

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
Critical %
Alignment with Business     68
Co-ordination with Developers
Purpose of Architecture
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 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:

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 True Technology Partners are the only organization in Australia qualified in PDAP.

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.

The model is available from:

Highly recommended!


Ho! Ho! Ho! Happy PraXmas!

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

Quality or Over Engineering?

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?

No Comments

So What Makes You an Architect?

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.