“Successful engineering is all about understanding how things break or fail.”
Substitute “engineering” for “architecture” and I’d argue that it still holds true 😉
“Successful engineering is all about understanding how things break or fail.”
Substitute “engineering” for “architecture” and I’d argue that it still holds true 😉
”Weeks of work can save literally hours of planning!”
Needed to remind a colleague of this recently 😉
I’m currently in the process of a job-change after some big changes in my current company. This has caused me to think quite a bit about which part of a job that actually makes it interesting for me. To make a long story a bit shorter, I have come to the conclusion that most of the stuff that is really fun and where I feel I add value to my organistion involves what I have come to call “non-linear trade-offs”**. On talking to my current colleagues I get the impression I am not the only one who feels this way and so I thought the topic worth of a blog post here – it’s been a while since inspiration struck anyway so I can’t afford to be too picky 😀
The linear trade-offs in an organisation, e.g. whether to add more money, resources etc. to something are mostly the domain of Line-of-Business leaders and honestly not very interesting for an architect. They are also inherently linear (or at least approaching linearity within certain boundaries) – if you add more people to a department it will have a higher capacity but also a higher cost and so on. These tradeoffs therefore depend mostly on the available means and capabilities of the organisation, the risk appetite of senior management and also on the commitments to stakeholders outside the organisation which is normally within the remit of the leadership to work on anyway.
Non-linear tradeoffs on the other hand are the tradeoffs where a little change of one side of the tradeoff makes a big difference on the other side. This may be positive or negative, but it is actually surprisingly often the negative part that isn’t well-understood, i.e. that you sometimes can invest nearly all the time/money and still only achieve a fraction of the value. The non-linear tradeoff is therefore the obvious realm of the architect and other like-minded professionals that are able (and willing!) to see through the “illusion” of what a problem initially appears to be and through to the real root causes (or the real obstacles) that need to be addressed.
An example of a non-linear tradeoff that I have seen in practice quite recently involves management reporting. If you want a management report on your sales that shows a certain number of data points that has a cost to develop and run – so far so obvious. Now, you might be happy with a report that covers 50% of the information points, even if it comes at 80% of the cost, because there might be other benefits in terms of time-to-value etc of going with a limited solution and then building on it later. However, only an idiot would pay for a management report that covers all the data points but is only 50% accurate, so whether that report is 50% or 20% of the cost of the “real” solution is immaterial – it’s still worthless!. That is an example of a non-linear tradeoff that is negative – if you are not prepared to invest in what is required to get close to 100% accuracy, then you might as well not bother starting the project at all (or abandon it if it is already running).
Another recent example for me is a fairly long-winded discussion on which tool to use to manage and improve some underperforming data management processes. The push from the business is to invest in a dedicated governance solution because that’s what you normally do. The pushback from yours truly and some key colleagues is that it is not necessary though. On paper this is simple – you go for the “proper” option. However, as most of the problems with the process in question actually consists of lack of clarity of what happens in the process, lack of definitions of what information needs to be collected, lack of clear and enforced roles & responsibilities etc. it would be possible to achieve a substantial portion of the value by putting the process into any tool – because that will simply not be possible without addressing most of the basic business shortcomings first. Taking this approach would also cut implementation time as you will use an existing capability, reduce overall investments and not add to the capability footprint of the organisation etc.
Good old Pareto raises a hand over in the corner and that’s obviously correct, but not all non-linear tradeoffs are close to an 80/20-split. That’s also fine, the important part is recognising that they are non-linear and so there can be large benefits in spending time on finding an optimum here 🙂
Now where I am going it this? Well, as mentioned in the beginning it has actually helped me explain to myself (and a few others) what I enjoy doing – and why I don’t really care about some decisions but will spend a long time on others. I suspect it might also be helpful in my future endeavours as I prepare to (officially) enter the world of EA in a few weeks time 🙂
**I came up with this term recently, but it could be that it already exists and I’ve just seen it somewhere without realising it, so I’m not planning to trademark it – and please don’t shoot me if you’ve seen it somewhere else 🙂
Do you understand the true cost of your capabilities?
The topic of this post first appeared in the comments section of a post by Gene Hughson and Gene latched on to my thoughts and posted a great follow-up of his own here. As the topic reappeared in some discussions at work over the last few weeks, I figured now was the time to write it up as a separate post here also 🙂
Imagine you buy a car and each month you pay off the loan/lease and the cost of running the car in full. When after 10 years of running the car and paying off every penny of buying and keeping it, it finally dies, you would think that you would be in the clear, right? You could now make a decision on whether to buy a new car based on the current cost of buying and maintaining a new car just as you did the first time. Well, if you are like most people you will have built you life around having the car and so you don’t really have a choice but to replace the old car when it’s finally dead – that’s the hidden cost of capabilities.
That cost of sustaining your capabilities also very much applies to IT-systems (you couldn’t really live without that CRM-system now, could you? 😀 ) but it is something that most organisations seem to overlook – and don’t think about until it is too late. It goes both for the “core” enterprise systems (ERP, CRM, SCM, PLM etc.) where it is probably mostly the cost of upgrades and patching rather than the cost of replacements that aren’t properly factored in, but still.
Where I would imagine it applies even more is when you delve into the more fast-paced layer of customer/consumer-facing applications in mobile etc. If you want to offer your customers a mobile application you have to consider the cost of updating it as new OS’es and new hardware comes along. Eventually, some of your underlying platform technologies may also die, but you still want to have the mobile app and so the cost of porting/converting/rebuilding it on to another technology stack comes on top.
This (hopefully) isn’t exactly rocket surgery, but as mentioned it does seemed to be overlooked quite often and it is also hard to predict what the real future costs are.
So, what to do about it? Well, if you can’t predict it, you have to find ways to minimise the impact when it does hit and so your two best friends are now architecture and strategy. Architecture to ensure that what is built will continue to be fit-for-purpose for as long as possible, and strategy to ensure that the new capabilities you add will be capabilities you need, and not just capabilities you want.
This way, there should be strategic support for continuing to invest in these capabilities and there should equally be an understanding (for management) that increasing your capability footprint will inevitably lead to an increase in your baseline cost.
I want to make it clear that I have tremendous respect for doctors and I don’t think that a comparison is entirely justified – after all the decisions I’m called upon to make on a daily basis are hardly “life-and-death”. Also, rather than anything remotely dangerous or traumatising, typical occupational risks for someone like me are likely to be the mental anguish of too many meetings without a clear purpose and the physical impact of 8-12 hours per day in an office chair…
I will however maintain that this works as a comparison, a) because of quite a few similarities in patterns, and b) because the context in which the doctor operates is much more clear-cut than the world of SW architecture, making it more easily understandable to “normal” people in a business (whatever that means… :D) .
Examples of where I find this analogy useful as a means of communicating what I do to those around me:
– 1) Listening to requirements is to me somewhat akin to listening to a patient describing symptoms and carries the same inherent risk of jumping to conclusions about what the problem really is. The doctor has to cut through the patient’s own ideas of what the problem is, the patient’s preferred solutions to said problem and any “false flags” because people simply don’t necessarily realise what is important to tell the doctor.
– 2) Like the doctor, the architect also has to balance short-term inconvenience/discomfort with long-term benefits for the patient. That means sometimes causing a patient to go through very painful procedures because they will give the best end result. Good doctors recognise that while some decisions clearly should be made by the patient, some decisions should be made by an expert that has the full picture and a more objective position on what the right decision is. I doubt that anyone would leave all medical decisions to the patient, but some people seem very prepared to insist that all IT decisions are made by the business (or exclusively by IT, which IMHO is equally wrong).
– 3) The doctor has to keep the good of the patient front and center, but the doctor must also be prepared to make uncomfortable decisions for the good of the patient (cf. point 2), remain objective while doing so and then be able to stay (relatively) calm and composed when someone afterwards starts to second-guess the decision they made.
– 4) Last, but not least: Patients normally come to doctors because doctors are experts and they are prepared to accept an expert opinion but the doctor understands the responsibility of making decisions based on the relatively limited input that a patient can provide. I have seen some curious practices for instance regarding sign-off of requirements and solutions – which, if you transplant them to a doctor/patient context and it becomes clear that they do not make sense at all. Some of them, when transplanted into this alternative context, would effectively mean that you had to be a doctor yourself in order to get any value out of seeing a doctor…
…or am I completely off here?
In response to yet-another-discussion at work about the “customers” of IT, I started thinking about coming up with a definition of what customers really are – and who actually deserves being called a customer within the organisation. My best shot for now is the following:
“A customer is any (external) person or entity that contributes a net positive cash flow to the enterprise”
Seems fairly simple (and no, it’s probably not perfect), but actually there are some important implications hidden in here:
The challenge in both cases is of course whether you have the tools and the data to see when the balance, on an enterprise-wide scale, tips from one to the other side (my guess is that most companies, especially large ones, don’t).
So does that make my sales department a customer (because they claim that they bring in all the money?) someone asks? No, because the sales department in itself does not contribute any cash flow into the enterprise, but it acts as an enabler to get external entities to contribute (they are also internal to the enterprise which to me is a disqualifier, but some would definitely disagree here).
And of course last but not least does it mean that all business functions are “customers” of IT? Not to me, because there is no positive cashflow into the enterprise from what the LoB functions buy from internal IT – it’s just moving money from one side of the cigar box to another. Of course there is a significant cashflow from the business, via IT and out of the enterprise to suppliers, partners and consultants but that’s a different matter. Again, it’s redistribution of funds from one part of the enterprise to another, or it is a part of the enterprise cash flow that IT controls on behalf of the business. Of course that spend has to be made in the best interest of the enterprise, but the spend in itself should not be a problem – you wouldn’t close down your procurement department because they are the company’s biggest spender, would you?
But wait, I hear someone shouting from the back, just because you’re cash flow positive doesn’t mean that you are profitable – no, and that’s what differentiates “a customer” from “a good customer” 😉
I was reading Gene Hughson’s last post yesterday – as usual well worth it – and found a link there that was very interesting. Especially the sentence: “Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change” really struck a chord with me. Not only is it very relevant for what I do, it also very relevant for other people’s perception of what I do and how I add value to an organisation. Unfortunately not everyone gets this, but hopefully this explanation can be used to improve the understanding somewhat.
I’ve long claimed that capturing the rationale for any business requirement/solution decision/whatever is possibly more important than capturing the actual requirement. Well, ok – as important as, then 🙂 Stumbled upon a good story today to back that up:
The problem is that if you can’t even explain why your own company does it this way, I am quite unconvinced that it could not be done better. For example, when more than a decade ago I worked with a large British newspaper company, I asked why their papers were so big. Their answer was “all quality newspapers are big; customers would not want it any other way.” A few years later, a rival company – the Independent – halved the size of its newspaper, and saw a surge in circulation. Subsequently, many competitors followed, to similar effect. Yes, customers did want it. Later, I found out that the practice of large newspapers had begun in London, in 1712, because the English government started taxing newspapers by the number of pages they printed — the publishers responded by printing their stories on so-called broadsheets to minimize the number of sheets required. This tax law was abolished in 1855 but newspapers just continued printing on the impractically large sheets of paper.
Many practices and habits are like that; they once started for perfectly good reasons but then companies just continued doing it that way, even when circumstances changed. Take time to think it through, and ask yourself: Do I really understand why we (still) do it this way? If you can’t answer this question, I am pretty sure it can be done better.
This isn’t just important to prevent bad decisions now, but also to be able to prevent bad decisions later when circumstances change and business evolves. If you can’t remember why you did something in the first place, you don’t have a clue whether it is going to be a problem to do something else 🙂
No, I don’t mean a negative attitude because although that feels great sometimes, I don’t think it is a particularly powerful way of accomplishing anything :). What I mean is “negative questions”, i.e. “what can you do without?”, “what should this not do?” etc.
Usually when developing requirements, the business stakeholder/sponsor has no incentive to remove any requirements, which either means you get a bloated list that isn’t realistic or you get to play the bad guy when you have to explain why the pitiful budget that was allocated does not cover the whole list of requirements. And sometimes both…
Even with an unlimited budget, asking what the requester can do without force thoughts about real needs and priorities, thus helping drive the really important discussions and tease out valuable information. In many of these situations you can “opt-in” on everything without any real cost and involvement, but you can’t “opt-out” of anything without considering the consequences first and that’s what the architect needs to take advantage of.
People are normally a bit taken aback when you ask them what a certain system/process should not do, but the answers are usually worth it – especially if they are open about their rationale for saying no. Try this technique and you may be surprised at the results as well.