The Business of Architecture

The rule of 2…

(or: which part of the creative process are you?)

I’ve found that when I start something new (new process, new functionality etc.) then it often tends to follow the same pattern, which means it takes:

  • 2 seconds to get the initial idea – that flash of inspiration that tells you that something could be done better/smarter etc.
  • 2 minutes to think though the concept and the implications and convince yourself that it is indeed a good idea.
  • 2 hours to write up a case for the change with arguments and benefits, a quick impact assessment etc.

But then it takes:

  • between 2 days and 2 weeks to convince those around you that it is indeed worth the hassle of making a change and upsetting the status quo.
  • between 2 months and 2 years to actually approve and implement the changes and see the original idea come to fruition and deliver value to the business.

And so you might ask, what can I use this for? Well, perhaps to think a little about where your strengths are and where you want to be in this cycle? Are you the person who gets the initial idea and sticks with it for just long enough to explain it to someone else, or are you the person that gets a kick out of following something for a long time to finally see it deliver value?

I guess there is no right or wrong answer, but for me personally at least it has made me understand a little better how long I prefer to stick with an idea before handing it over to someone else – and of course what projects I should try and avoid getting assigned to 🙂

On architects and doctors….

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?

How to recognize a customer?

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:

  • In some industries, you may sell a ton products to certain people at very little to no margin but the resulting scale drives down your cost of operations overall and the overall relationship thus ends up being very cash-flow positive.
  • In other industries, you may sell some products to people where you then spend so much money on marketing contributions, after-sales service, various long-term incentive and retention schemes etc. that your relationship with the “customer” actually ends up cash-flow negative overall.

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” 😉

System implementation tips…

A million and one (and counting…) of these already, but here’s my view. This is based on my experience with the SAP ecosystem, but I am fairly certain that most of it applies to most other ERP- and ERP-like enterprise software packages as well. It is more or less the antithesis to the large, System Integrator (SI)-driven business transformation programs that I have been part of for the last years, but these are hard learnings based on many hours of my life so that must count for something – right?

So, very quickly why doesn’t the “business-as-usual” approach work?**:

  • “Waterfall” project models give a very long feedback cycle on the quality of the chosen solutions as the whole project is effectively design-build-test-deploy-evaluate. The long feedback cycle also prevents effective business feedback on the solution because the “real users” don’t see it before it is too late to make significant changes. To quickly and effectively deal with unforeseen technical issues and weak business requirements you should aim for design-build-validate (cyclic) and then test-deploy (linear).
  • Functional silo-thinking overlooks end-to-end solutions: In any (complex) business process, end-to-end alignment is king because the hard part is not solving a problem, the hard part is solving one problem without causing five new ones in a different area of your end-to-end process.
  • Functional silos impede progress: If the focus from program management in designing/building/testing (and this might be typical for SI-driven programs) is “why do you have so many issues in sales” then the challenge for any functional team will be to reduce the number of issues – not to deal with the issues causing the biggest impact for other areas. This might paradoxically lead to cases where teams prioritise the simple issues to make their stats look better, rather than solving the hard problems that genuinely impede progress and reduce solution quality. Defects and other issues should therefore be rated in order of their importance, but the criticality needs to be two-axis, both business/solution impact and project/progress impact.
  • Functional silo thinking prevents focus on real results: The ultimate goal is a successful business transformation – not just a successful golive. So instead of a focus on outputs, the focus must be squarely on achieving the desired outcomes.

**Obviously, it does work in the sense that stuff gets delivered. My claim is just that by following these guidelines you’ll be able to get a) more stuff done that really matters b) more done for less money invested.

Now, in terms of more practical advice, here are a few of the most important points for me:


  • After basic solution scoping and initial design of the solution, adopt a semi-agile approach instead of the normal design/build/test/deploy waterfall:
    • 1) Configure/develop the basic standard process and test with the business experts to ID gaps in functionality.
    • 2) Build the “core integration” (interfaces) and major functional enhancements that significantly impact the process flows. Repeat testing/validation to fix issues and ID additional gaps.
    • 3) Once the basic process is stable and working E2E, build on other functional enhancements and “cosmetics” such as outputs, forms etc. that are necessary but has less impact on the E2E process flow and stability of the process (this would include any unavoidable, legally-mandated outputs etc. because they may be important but they do not change the process)
    • 4) Feed each sub process into the testing cycle once it is ready (or via a stage-gate procedure to allocate scarce resources between development and testing).
      This should mean that the most basic flows and those with the highest business benefits are handed over to testing first and receive the most attention.
  • Use a project manager/lead for each E2E process to manage scope, ensure gaps are constantly prioritised and that overall progress is maintained.
  • For integration- and acceptance testing with more people/functions involved, a key metric should be rate of flow, which can be helped by “loading the test pipeline from the back”. This means e.g. making OTC-scripts that are simple in sales/logistics and complex in finance and then building up the complexity in sales/logistics gradually. This should ensure that you quickly get testing to a stage where everyone has stuff to work on, instead of having massive complexity in sales blocking logistics and finance from doing anything for a long time.



  • Use a small team of business experts and system experts with focus (= 100% assignment to the project) and a clear mandate to make decisions on behalf of the business. Only expand the team if it is absolutely needed to fulfil specific needs in terms of capability or capacity. Work normally expands to fill the available hands anyway and having as few people in the loop as possible reduces complexity and speeds up issue resolution.
  • Let the business leads decide whether to add more people to the project or not, not the SI. When what you are selling is people’s time, it’s no wonder that the automatic response to any sign of trouble usually is “we need more people”. Your business leads will normally be able to judge whether there is really a benefit of more people or whether the marginal cost/complexity of enlarging the team outweighs any benefits (because at some point it will…).
  • Build the project organisation on a process-based E2E structure and responsibility, e.g. an MTC-team responsible for making the entire market-to-cash process work instead of only the sales part of the process. Use these teams to ID the process variants of the business and prioritise them based on business value (usually share of revenue/profit), frequency of execution and customer impact as part of the initial scoping and design phases.
  • Functional alignment in sales, logistics etc. should be used as well, but mainly to prevent inconsistent approaches and conflicts where there are overlaps in configuration and functionality. Each process lead needs to be accountable for this cross-functional alignment activity as well.
  • Note that this is a big change in the way of working for many organisations, so if you’re concerned that this is too much to swallow, then start out with a functional organisation during requirements gathering and move into the process organisation towards the start of testing. A project like this will always be a matrix-structure anyway, so the only question is really which part of the matrix structure that leads and that should then change over time as the project progresses.


Requirements gathering:

  • When designing and building the solution, don’t aim to solve the business “how” but the business “why”. Differentiate between “business requirements” and “solution requirements”.
    A business requirement is a request for a specific output or outcome and it may be grounded in a real need – or it may be grounded or in legacy thinking, misunderstandings in what the system can do, stakeholder conflicts, weak/undocumented business processes and so on.
    A solution requirement on the other hand is an approved addition to the solution that has been screened and assesed based on at least three key criteria:

    • 1) It adds overall value to the business.
    • 2) It passes at least a very simple “value for money” test on business benefit vs. cost to implement.
    • 3) It is delivered in the most technically appropriate way, taking into account as many technical and business process considerations as needed (both long and short term).
  • Ensure that nothing is accepted as a solution gap unless the business rationale for the gap is captured and the impact is clear enough to be used for prioritisation. The key reason for this is that requirements change and/or become obsolete over time and so the rationale will be key to managing the solution after implementation. The rationale is what tells you whether something needs to be considered when new requirements come along or if it can comfortably be ignored or changed because its out of date.

And last but not least: If anyone comes in claiming that their solution design or approach is “best practice”, kick them out of the room as quickly as possible before they do any real damage… Always ask for rational for choosing something vs. your requirements. You’re not interested in what worked for others, you’re interested in something that will work for you 🙂

”Inverted” business cases…

As an architect, every so often you have to make a business case for something where you hit some unknown factors that can’t really be quantified, at least not without a significant margin for error. Two typical examples for me have been firstly “risk avoidance” type investments in process compliance tools etc. where there’s an upfront investment but no real ongoing business benefit (or even a minor ongoing loss due to lower process efficiency). The upside of an investment of that sort is typically to avoid audit failures, avoid submitting incorrect tax/duty reports etc. which may not happen, but will be extremely costly if they do.

The second part is a benefit where there is a profound disagreement among stakeholders on the value provided. One example of this scenario: Many consumer-goods companies have direct distribution to end-customers in many of their markets. A typical discussion is whether this distribution operation should be outsourced or kept in-house. Most factors in this discussion can be quantified; capacity requirements, fleet utilisation, running costs, driver qualifications, training and so on.

The one factor that definitely can’t be quantified (well, one of them, but a big one) is the value of having your own people visit the customer on a daily basis. Everyone agrees there is probably some value in this, but how much exactly and how much it is actually utilised is generally impossible to pin down. So, one suggestion to break the deadlock is to “turn the business case on its head”, meaning instead of asking “how much is this worth to me?” you ask “is this worth what I am paying for it?”.

In the example above, that means for example taking the difference between the two cost models and dividing by the number of customer visits made per year. That gives a cost per customer visit which is then the premium that we pay for the privilege/opportunity/hassle (depending on your viewpoint…) of distributing to the customers ourselves. Having that figure then allows for subsequent discussions along the lines of “what else could we get for that money?”, which then in turn allows you to zero in on the exact value for the business.

Using this approach doesn’t completely solve the problem of trying to quantify the unquantifiable, but it at least gives some options for asking questions, mostly along the lines of “does this seem like a fair price for what we are getting?” or “could we do more with the same money if deployed elsewhere?” etc.

These questions and answers in turn give a much greater clarity and a much more solid base for discussion than each stakeholder picking (and defending) their own random savings figure – which seems to be a fairly typical alternative.

Defining architecture…

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.

When to act and when to wait?

OK, maybe a bit too broad as a headline, but this at least partly covers an oft-seen scenario when part of the organisation want to jump straight into building a solution for a given problem, while another part of the organisation wants to dig deeper into the problem first. In my experience, using the questions below is a good starting point to see if you are actually ready to start working on a solution – and it can defuse any impression that people that want to do more analyses aren’t just “slow” or “timid”.

Presenting the different responses to the questions (e.g. the five radically different perceptions of what the basic problem is) can be a very powerful way to show senior management and/or stakeholders without detailed knowledge of the situation that there are more versions of the truth out there. However, it can of course also be used the other way, to show that everyone are aligned on the problems and the best way forward is actually to try to build a fix for the problem and get some feedback on the effectiveness from the people that need to use it.

  • Problems and (potential) solutions:
    • Do all key stakeholders agree what the basic problem is? (you might be surprised how often this is a resounding “No!”…)
    • Do all key stakeholders agree on the (initial) scoping and prioritisation of issues?
    • Do all key stakeholders agree on the desired business outcome?


  • Impact:
    • Can we define clear success criteria for a solution and objective ways to measure them?
    • Can we predict the knock-on effects of what we are changing (systems/processes/organisation)?
    • Can we predict how a solution impacts our current way of doing business?


  • If answers are mostly YES = consider building a “minimum viable product”-based pilot and trying it. Use the collected experience and feedback from all stakeholders to refine and improve the solution.
  • If answers are mostly NO = consider doing more analysis and alignment to better understand the problem and it’s context. This will ensure that you have a solid foundation for any solution and hopefully avoid taking too many detours and wrong turns on the path from problem to solution.

Rational rationales…

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.

From here.

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 🙂

The power of negative…

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.