Do we need yet another framework in IT (Information Technology)? Isn’t there a plethora of them already? That’s a good question, and I have a simple answer. Yes, frameworks galore in IT, they are ubiquitous but they have a point. IT is nothing but a collection of components in search of a purpose, and the framework is the purpose at least partially. Frameworks typically appear at a certain level of maturity in the business; it means the sandbox playtime is over, and it’s time to get serious. To get serious entails, among other things, moving to a higher level and scanning the field from a higher vantage point to gain a more holistic and comprehensive view of what’s happening below, and then continuing accordingly.

So, what’s happening below? The fact is that IT has progressed tremendously over the last 30 years. I remember when I started out, I read a statistic that said that almost half of the large projects failed, as in, they were never delivered. Nowadays, it’s extremely rare for large projects not to be delivered. It doesn’t mean they are all successful and function up to spec, but whatever ills they suffer, be it security, performance, scalability, functionality gap, they at least work to some extent. The failure is now more sophisticated, and that’s why we need a different way of measuring success. In the past, if a project was not delivered, or was delivered late, or over budget, everybody could see that; there was no method or tool needed to discover that. But now, it’s not so simple.

Today, even a basic requirement, the most basic of all in IT, namely that “IT follows business goals and objectives”, can be difficult to prove as missing. In the past, many projects started from scratch, and so it was easy for IT to diverge over time from business goals, especially in a waterfall method where business and IT only worked together at the beginning, say, the discovery and design phase, and then, typically, IT was left to its own devices to deliver the project. And that’s when the business found out that half the requirements (I am exaggerating) were missing or incorrectly delivered. Today, most initiatives start with an established system which is being extended, and they use “Agile” to keep the business on top of things. It’s much harder for IT to miss the business goals in this environment. It’s not that it doesn’t happen despite “Agile’s” promises to the contrary, but if it does, it’s hard to diagnose.

A major problem today is often the exact opposite of the “IT follows business” axiom. Software companies today often work on the reverse of that principle, “business follows IT”, which is especially true for tech businesses, software and and especially SaaS providers. I wrote about this in another blog about the lack of applications in tech businesses, where everything is turning out to be a technical service rather than a business service. In the case I was writing about, the business grafted its services onto the existing technical functionality. In one project, they actually had a requirement that the new business payment service they wanted to provide had to be able to use the existing IT infrastructure, a classic “cart before the horse” aka “business follows IT” case.

How do you diagnose something like that? You need a sophisticated tool and methodology. That’s what “Architecture Maturity Assessment” is supposed to deliver.

And on the other end of the spectrum, I have worked for a company that just hired a new Chief Architect to head its significant architecture team. In the first meeting between him and our small team, the chief made an extraordinary claim; according to him, the enterprise architecture maturity level was 0, despite there being 10-15 enterprise architects presumably working on some output or maybe just sitting on their buts, year in year out. I hope I don’t have to state the obvious but I will, it was an extraordinarily stupid thing to imply that a whole group of people (EAs) have produced nothing worthwhile because that’s what 0 means, nothing, nada, not even empty space. I didn’t get into an argument with the guy, because I was a contractor and he was a big shot now. But I remembered it and thought that one day I’ll produce a system that will disprove such blatant lies. So here is to you, Mr. Chief Architect, use my method to get the state of affairs at your sandbox rather than making empty, totally unsupported claims that boost your ego at the expense of the morale of your co-workers.

And this is the system: Architecture Maturity Assessment.