During the Christmas vacation I was working on the renovation of my IT infrastructure, and cleaning up, and while I was doing that I found a completely misplaced note I once got from a very good IT professional: Peter Dieleman. The note starts with “Sweethearts”, provides us with some basic wisdom, follows up with a quote of Edsger Dijkstra, and ends with the suggestion not to overcomplicate things. But in the note I found a sentence that triggered me to write about something that is an important basis of my approach to Enterprise/IT Architecture.
Peter is still active (mainly helping large organisations/environments/projects get out of disastrous situations) today. When I started out in actual enterprise architecture functions (Peter abhors such titles, he calls himself a ‘computerkundige’ or ‘computerician’ if you will) he was an important influence. He is also the source of a story that makes me call Ludwig Wittgenstein ‘Uncle Ludwig’. But I digress, as usual.
Anyway, Peter’s sentence from all those years ago reminded me that there is something in my EA workshop that harks back to a post on InfoWorld that I have written three years ago (and I never found the time to repeat here). InfoWorld has made it impossible to write stuff with images other than nonsense stock images, so I hardly put anything there these days). From that post:
Suppose you’re a dairy farmer. You keep cows for the milk they produce. One of the systems you use is a milking machine. The functionality of that system is getting the milk out of your cows. The farmer’s cows need to be milked twice a day, if not they can even die. Suppose milking your cows with this machine once takes a whole day. Question: can this machine fulfill the function that it is meant for?
The answer of course is no, but in IT, strangely enough, people argue that the answer is yes. They argue that the function is milking and how fast it is done is an NFR (non-functional requirement).
In the early days of IT, when users were confronted with — for instance — unacceptably slow behavior of IT systems, the software engineers called these requirements “non-functional.” After all, they had written perfect milking logic, hence “it is not the fault of the logic that we produced that the infrastructure is not fast enough.” Logic is logic; you can’t blame it for anything. For the software engineers this had the added benefit of shifting blame, of course. Ironically, the software engineers have always been the main originators of these kind of problems and throwing more hardware at badly written software is a major anti-pattern.
Nonsense non-functional requirements | Infoworld
The actual sentence from Peter was:
“Mathematicians […] have never learned to think in algorithms but only in terms of definitions and functions.”
Peter Dieleman
And this was exactly what I’ve also made part of the workshop on EA I’ve given a few times now. In that workshop, I start the section “Blame the mathematicians!” with the following picture:
In IT we often talk about the function and the ‘non-functionals’, such as performance, security, etc. So, let’s start with that all-important primary ‘function’. It might be ‘milking cows’, but in my life it will be something like ‘paying a pension’, ‘buying stock’, ‘provide insight for participant’, etc. The next step is to follow it up with a set of key presumably ‘non’-functionals:
And the fun starts. Take for instance doing some asset management transaction that needs to be done within a certain time frame or the chance is gone. Example: every morning we look at the available cash and if there is more than we need for the day, we put the rest of it to good use: we do intraday lending on it, making some extra money for our customers. This is part of the function ‘cash management’ and for large asset managers it makes them millions. But there is a catch: for intraday lending, the best deals are at the start of the trading day, so you need to know at the start of the trading day how much is available or you’ll miss out. Hence, if the function ‘calculate available cash’ — which is part of your operations before the markets open — doesn’t perform well, the numbers will arrive too late and the profit is missed. In fact, if the amount is not known by noon, no money can’t be made at all anymore.
Now, from the mathematician’s perspective, the performance is not part of the ‘logical’ (‘mathematical’) function. There is no ‘performance’ in functional mathematics. For mathematicians, “y = x sin(x)” is the definition of ‘y’, not the production of ‘y’. You put inputs in — x — and you get a logical result out — y. Time and place, physical reality, are not important in mathematics.
From the perspective of the enterprise, however, being slow means that you might as well not have the function at all. And the same is of course for something like continuity. Poor performance or disaster recovery directly undercuts the primary function everyone is so interested in. Or even completely nullifies it. You must be totally ‘lost in abstraction’ and an out-of-this-world mathematician to maintain the function is still there if there are no results. Logically/mathematically, yes. In reality, no.
The other tiles in the figure seem less direct. But take security. Being able to ‘buy stock’, but without the required security is something that might look ok to the mathematically-inclined, but it is unacceptable for the organisation, given dangers like ‘front running‘ and their damaging effect on stock buying itself. Which illustrates another problematic aspect of the mathematician’s approach: it is too narrowly focused. It is a splinter of all that is coherently relevant. We need to access functions from the enterprise’s perspective, not the mathematician’s perspective. And from that perspective, security is a matter of life and death. Having the primary function in a mathematical or logical sense, but with all your data ransomed is pretty much the end of you.
The other tiles around the central function are key as well. From the enterprise’s perspective, not having identity and access management means that there is no decent border that defines your enterprise, so you aren’t really here (crazy link, sorry, but brilliant movie). Without logging and monitoring you are not aware of what is happening, another key element of staying alive. And finally, if you cannot change your function, you are doomed in a changing world. In other words: all of these are functional necessities from the enterprise’s perspective. And we’re not done yet:
because we have many knock-on effects. To be able to change in a good way, we must manage change. That may be in a strict way or in a more agile way, but manage it we must. We must control what is there in our huge landscapes of machine logic and data, so we need configuration management, the management of what state our landscape is in (these days more and more fully automated), and data management. We need to manage costs. And we need to be in control of all those tiles, so we need risk & control transparency. But that isn’t all, because those new parts have requirements themselves, like having a Configuration Management Database to support your configuration management, or workflows to support your change processes:
And to make matters more complex: that risk & control isn’t really a tile at the side, it is everywhere across all tiles. We actually need more than two dimensions to show all of this.
Being singularly focused on that one tile in the center:
is a bit naïve, is it not?
So, you might understand that I find the term ‘non-functional’ one of the more damaging terms in our industry. It shows myopia. If you wonder why your changes and projects are slow, often it is because you only take these into account when it’s too late. E.g. the brilliant new blockchain innovation, that you engineered in a playground somewhere, has so many security implications that when you want to move to production, it turns out your design breaks several tiles around the primary functional one. Back to the drawing board because breaking those tiles may be non-functional for your innovation, but they are essentially functional for the enterprise.
Talking about ‘essential’, I must thank colleague Ramon Billar for coming up with the right term to use from now on. They should not be called ‘non’-functionals, they should be called (the other) ‘essentials‘. In a digital society, your ‘digital enterprise’ cannot function without them.
Of course, in the reality of enterprises, the essentials cannot be ignored. They are indeed ‘essential’. Reality bites. But the way they enter the process is often far from efficient. What often does happen is an unhealthy fragmentation of concerns, e.g. we let the business worry about the primary function and we let the security people worry about security. We focus on shiny objects such as apps and cloud and leave the architecture that defines our future agility for others. And we gripe about IT when the needs of the enterprise’s essentials are brought into the game. We want to use that shiny new IT product or that data analytics cloud service and IT bothers us with security and disaster recovery and all that other junk. Conflicts abound (see: The worst EA anti-pattern of them all). What you need to do is bring them in in a holistic and realistic way.
For me, the concept of non-functionals is a mathematically born aberration in IT that is true in the deepest recesses of programming and logic but not in reality. You might think that to label the essentials alone (as ‘non-functionals’) gives them visibility and prominence, but the label itself belies their importance in the board rooms. Except for security these days, as ignoring it is so dangerous and effects are so obviously immediate.
Several organisations have started to call these essentials of the digital landscape together the ‘health’ of our digital landscape, and so have we. And we have started to manage them holistically.
But doing that all is not easy, it requires a cultural change as far as I’m concerned. To really get that going, you need to make sure that the owner of the primary function feels him- or herself to be the owner of all the essentials, of his or her (part of the) landscape. And yes, he or she doesn’t have the know how to manage them all; they will need help from the specialists. But they need to know something and they need to pay attention. The days that one could almost completely ignore the intricacies of the digital domain are past. Welcome to the real ‘digital enterprise’.
You compare it to the way a board of directors depends on the input of the chief legal counsel. A board member doesn’t need to be a legal specialist. But he or she does need to be able to talk with legal specialists and understand them. The same is now becoming true with respect to the now so essential digital parts of our organisations.
Focusing on your primary function is essential, true. It is why you are in business in the first place. But in the huge, complex, landscapes of machine logic and data we are in now as a civilisation, not equally paying attention to the other — IT-driven — essentials can damage your primary function in such a way that it could as well not be there. And for that, I think it is important to prevent the splitting of the ‘ownership’ of these essentials. Owners of functions should become owners of landscapes, health included. With good support and the right checks and balances, you optimise your design decision making. Which is sorely needed in today’s digital world.
In short:
It is essential to pay attention to your primary function. It is functional to pay attention to the other essentials.
[This article was published before on R&A]
One Comment