Archive for category Uncategorized

Architects Don’t Know What They’re Doing!

This is the second in a series of articles that makes the latest research into architecture available 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 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 it seems that some of that ‘basic research’ has finally been done (Hope 2015 The Critical success Factors of Enterprise Architecture) 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’ choices don’t tally with the academic research.The analysis shows that the only factors significantly correlated with success were Monitoring and Compliance, Commitment to the Use of Architecture, Consultation and Communication. The use of methodologies, strategy and tools did not correlate with success.

Hundreds of Architects were surveyed about their training. They were asked to classify their training 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 getting a masters even if it is just to be keeping up. But the really interesting information is about the vocational training.

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

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

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 research shows (see below) that the actual method used seems to be a lot less important than the practice used to implement it. (Hope, Chew & Sharma 2017 The Failure of Success Factors)

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%

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 glaringly obvious problems. 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

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

$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.

2 Comments