Home > EA > Architecture of Responsibility: Case Study

Architecture of Responsibility: Case Study

This article is supposed to serve as a justification of Nick Malik’s post about responsibility of architecture. I decided to publish a real (though made a bit anonymous and quick) case to support his viewpoint. Additional reason is that is fits to my other experiences as well, so it might not be far away from yours either and perhaps helps a bit:


An international company, present in multiple markets, but mostly of centralized nature of organization. Organization is structured in typical and fairly independent product verticals, with also IT independent in each vertical. Architecture governance is in place in terms of a process and committees for approving solution architecture in projects in order to comply to the strategy, target architecture and principles. Development methodology is agile, business and IT are quite close to each other with very agile and more informal interface.


The assessment was carried out in the form of interview, comparison of original intentions, real work done and results produced.

These were the general findings:

  • Varying and generally very low understanding of what “governance” means
    This might be just a problem of companies where English is not a native language. “Governance” seems to be very fuzzy term, not tangible, understood very differently. From “having a process in place” (to achieve or manage what is unclear), through “having directives to be followed” to a very generic “managing the company right” understanding.


  • Reality away from the intention without noticing
    We claim one think while doing another. Once there is a process, roles, tasks, meeting minutes, KPIs and all that fuzz around, it seems to be rather difficult to see if we are in fact achieving what we envisioned.
    Regardless KPIs, which are there often more in order to justify what we do (and perhaps also to “look good”) instead of providing an objective view on the result. And also quite often I dare to say it is not even that easy to actually come to such KPIs without crystal clear and MEASURABLE targets.
    Until we stepped back for a while and had a look on the whole governance thing, we did not realize that what we are doing is of a value, but not the value we originally wanted. I’ll be more concrete in the picture below.


  • Lost in technical discussions
    Architecture is perceived as “something technical”. Whenever more controversial matter (read: more opinions on the matter) came to the desk, it always ended up being discussed on a very low technical level regardless the audience (up to the C-level).


  • Low business buy-in
    Business ceased to be interested in techie ramblings and found more important things to do. Naturally. 


  • Deciding without information
    When urgency calls and a decision is finally made, it’s rather a rule than an exceptions that most of the following bits of information are missing: what are the consequences of the decision, what are the risks (yeah, really, also this can be missing, no kiddin’), to what level business requirements are fulfilled (feature completeness), to what level non-functional requirements are fulfilled (performance, availability, scalability…), how much the solution architecture fits the target (architecture compliance). If you are braver, you might want to see dependencies, assumptions, complexity… Effort is usually the one that’s usually there, though often very wrongly estimated. This is that kind of information that makes the difference for decision makers.
    However, the fact that all this is missing is not obvious in the mist of all information, data, opinions, interests, rumors flying around.


  • Unclear responsibility
    People didn’t know who should actually make architecture related decisions. These questions came up only after! the investigation:

    •  “Is it a committee of architects that decides?”
    • “Is it a committee of managers that decides?”
    • “Is it IT or business who decides?”
    • “As a person, am I here to just listen, provide input or be part of the decision?”
    • “When something goes wrong, was I heard when I disagreed?”
    • “If I decide, is the decision followed?
    • “Can I make others follow the decision?”
    • “Who made any of the past decisions?”
    • “Who gave me the authority to decide?”
    • “Are people aware of decisions made?”


  • Decisions happen elsewhere
    Many key decisions happen actually somewhere “downstairs” on the go: made (un)intentionally by developers, team lead, PMs, business analysts… Than a funny game can start when real decision makers start “covering their ass” and the fact that they were not even aware of some decisions taken in their domain.


Now in the context of Nick’s article, it actually all comes down to two key topics:

  1. Unclear responsibilities
  2. Lack of information

Fixing these two addresses most of the bullets above. I won’t go into details in how we actually set it up. If you’re interested feel free to drop me a mail. But I list at least few ideas that helped us a lot:

  • However your responsibilities are set, make them really clear. Answering those questions above might help.
  • Responsibilities can be delegated! Mind that. Accountability cannot.
  • Document who made a decision. Not so much for the later reference to chase down somebody for a bad
    decision, but rather as a need to find out clearly who is the real decision maker. That’s often not obvious even if you have your responsibilities clear.
  • Collect opinions of all involved parties. Make clear that their voice was heard. It’s much easier than to get their commitment even if the decision goes against their preference or belief. Do not underestimate this commitment. It’s something that can bring down even a huge endeavour!
  • Find out from your decision makers what information they need. Try to offer a sample information set, even better on a sample project they are familiar with and show what they could get. Let them pick what they really need to be able to discuss and decide a topic.
  • Do not worry very much about showing what information is missing (assuming you are specific). Show them a decision document that’s almost all just “blue” (our color code for “Information not known (yet)”). I bet they would ask you to find out, which gives you a bit of authority to push others to deliver information you need.
  • Don’t worry that much about showing that you are not perfect. It’s about how you sell your endeavour of getting better. You can have a look at the picture below, this is how I did it (to a middle management, so take it more as a sales picture).
  • All in all, you can achieve a lot with fairly simple changes. Managers listen to that.



Sure, there’s a pile of challenges ahead. Once you get support for this kind of transparency towards management, it allows you to start tackling these challenges step by step.

Categories: EA
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: