Here in Saudi Arabia, we have our local Enterprise Architecture framework which is called the National Overall Reference Architecture (NORA in short and not to be confused by the other NORA in the Netherlands) which is developed and maintained by the Saudi E-Government Program (Yesser Program).
To be frank, I have never adopted this methodology with my previous government employer or even worked on it while I was actually working in Yesser; yes I had my input funneled toward the Government Data Reference Model (DRM), presumably, but never engaged with the Government EA office at that time due to my short stay with them. Nevertheless, I can’t enough express my open hatred toward anything that is celebrated as the de-facto standard for Enterprise Architecture since my initial confusion with TOGAF in the 2000s. But the NORA reference architecture has its own place in my heart as it affects much of the public sectors in Saudi Arabia.
In the simplest words, NORA is more a governance framework for the government agencies that were initially designed, as far as I know, as a “tool” to be used, as far as I know, to assess the maturity of the government agency to approving IT budgetary plans. It is compliant with TOGAF and FEAF and follows the classical Business Systems Planning approach as popularized by IBM in the 70s. So far so good! But this simple explanation of NORA doesn’t deliver the total catastrophic derivatives that it brings to the table.
First of all, have a look at their 400 pages document. And now consider this document got thrown at a poor soul by her pseudo-CIO of an agency with 200 employees! She will have the same shock that I got more than 10 years back. And the course of action, at best, will be to waste millions on a predatory consultancy firm that will just shuffle some of its decks and deliver it to the agency which will result in adding complexity to the enterprise. Oh yea, and that poor soul who found herself in that position in the first place, that is if she didn’t resign, will eventually that find herself as the Chief Enterprise Architect since no one ever saw the document. And the end result is waste of money, time, resources, talent, and more resent toward Yesser and anything Enterprise Architecture.
I have been interviewed multiple times for public agencies for the head of EA office just to take this NORA thing and make it compliant with whatever they have their just to please Yesser and later on win a prize or two at their bi-annual event.
Let’s an overview of the methodology steps:
Just from this figure alone, it will overwhelm you with so much stress that might break your mental stability for a day or two. Aside from the things your IT manages, NORA targets IT, so the meaning of enterprise is already lost, you get this thing that you must fit into your already chaotic schedule to get the blessing of Yesser and the chain of managers.
Look, I get it; we must have a common approach for EA architecture, but this doesn’t mean compositing multiple frameworks and word and throwing it in a document and calling it an EA methodology. Just an example, in step or phase 3, or whatever is called, you have the Analyze Current State, and under it, you have a SWOT analysis. Please excuse my ignorance, but how the heck can someone proclaim that an EA analysis needs a SWOT analysis? For what exactly? As found on wiki, I will not go into management and academic papers:
SWOT analysis (or SWOT matrix) is a strategic planning technique used to help a person or organization identify strengths, weaknesses, opportunities, and threats related to business competition or project planning.
https://en.wikipedia.org/wiki/SWOT_analysis
So, an IT business unit within a government agency THAT has absolutely no market competition and is more about digitizing some of the value delivery related to regulating aspects of the citizen/business/government relationship will do a SWOT analysis at the IT level rather than the strategical level! OK, I might misunderstand the SWOT concept, so let’s look at the reasons to do a SWOT analysis. So on page 100 (There is no apparent versioning number for this document but whatever), you will find the SWOT usage:
3. Carry out a SWOT analysis (Strengths, Weaknesses, Opportunities and Threats)
4. Compare some of the SWOT analysis with other external reports like United Nations, and direct comparisons with government agency in another country or region.
5. Document the SWOT findings and comparisons into the external environment analysis report.
Then what? What should I do with that SWOT analysis once I wasted a couple of hours if not days? Well the revelation is found on page 105:
This stage begins with the completed EA requirements, environment analysis reports (both current business and current IT landscapes) and the SWOT analysis report from Stage 3. Note that the EA Governance Committee may also provide additional strategic requirements at the end of Stage 3.
So I am doing a SWOT for the sake of just doing it!!!!! OK, I admit it, I am mentally challenged as like one of my close friends once said to me: “I don’t know how you graduated from the university.” So, please if anyone can help me in fitting this SWOT thing then please explain to me as you explain to a 3 years old and at that time maybe, and I say maybe, I can find a place in my tiny brain to process the logic behind it. Do you need some help from me, well here is a SWOT “template,” like you need one, that is included in the document:
Does this resemble anything related to an EA practice? Well, I leave this to you.
What do you want more inconsistency in the document? Well, let’s have a look at the maturity model, and specifically page 345. Here, NORA states that the maturity model for the agency EA is adjusted based on four pillars:
- Architecture development area
- Architecture process area
- IT Investment and acquisition strategy area
- Enterprise Architecture area
So among the four what seems out of place? Well, for sure it is neither the first two nor the last one. So, could anyone please tell me how the IT investment and acquisition has any relation to the EA practice? And BTW, it seems that they mistyped the acquisition while they should have instead used the term requisition. And if you dig deep enough in that pillar, you will find that it is all about templating RFPs and establishing procurement processes (Not going to lay there are multiple useful RFPs templates in their website but they don’t point you to them)
And to make the maturity calculation looks fancy and sophisticated, NORA suggested the following “formula” to obtain the maturity score:
And yet, I have to see some formulas in an EA outside the academic debates and EA KPIs.
Look, I know that I will get many replies to some of the points I outlined here, I can go on and on but it is a 400-page document, and I know many people who are experts in the EA domain worked on that document. I honestly admit that I am criticizing a lot and do less which makes an effort on that developing the document valuable. But at one stage during the development, someone forced the authors to add more until the document façade changed purely from light weighted EA model into this conglomerate thing that included many stuff related to IT but not the architecture practice.
I hope we see a revised document with more concise information and processes, and I am pretty sure that Yesser will have another look at this document in the short run. And until then, I petty the people who are forced to undergo this nightmare just to please their managers and Yesser.