Architecture is dependency management

Posted: December 21, 2012 in architecture, design, Uncategorized
Tags: , , ,

People always seem to want to make IT / Enterprise / Software architecture much more complex than it actually is. There are a plethora of frameworks, tools, approaches, methodologies etc. that all claim to offer the solution. I’m sure you’ve seen them. Maybe you might find of them are useful, but in general they distract from the point that architecture is actually really simple.

It is dependency management. No more. No less.

This is a viewpoint I have come to after many years of watching software, technology, people, organisations and the interactions between them. My outrageous claim is that by thinking about architecture as dependency management, you’ll become a better architect (or if you’re not an architect, better at working with them).

What do we mean by dependencies?

To give you a flavour, it’s worth thinking about the different kind of dependencies that can exist:

Business dependencies: a business needs capabilities in different domains to achieve it’s strategic and operational objectives. This is a dependency between the actual success of the business and the business / IT capabilities that support it. Without managing this dependency, your business will not have the capabilities it needs to succeed.

Process dependencies: if you think of a business capability as consisting of a set of concurrently running business processes (again, can be either human or IT) then it is usually the case to find many dependencies between these processes their respective sub-processes/steps. These kind of dependencies often sound like business logic when described: e.g. “Customer must be registered in customer database before order can be shipped”. Fail to manage these dependencies and your business processes will break down – possibly in expensive and embarrassing ways.

Application dependencies: running software application (which may be supporting part of a business process) may have many dependencies. Perhaps there is a dependency on another application (via a message queue) or a dependency on the application logs being correctly cleared. Fail to manage an application dependency, and you’re probably going to suffer some serious downtime at some point.

Infrastructure dependencies: some software produces depend on particular operating systems or hardware configurations. This is an infrastructure dependency. Without managing it correctly, your software won’t work.

Software dependencies: software almost always has dependencies on other software. Typically this includes: various libraries, the presence of other software processes at runtime, and probably a dependency on a software platform such as the JVM.

Code dependencies – at the micro level, individual pieces of code have dependencies: this function calls two other functions, and so on. Normally this is too low level to count as “architecture” but can still give some big insights. For example, architecting your software in a way that minimizes dependencies on mutable external state (e.g. pure functional programming in Clojure) makes code modules much easier to test and reason about.

Standard dependencies: some processes and systems (both human and IT) require standards to operate effectively. What information is collected? What format should it be in? What checks should be applied?  This is a standard dependency. Someone needs to decide / establish a standard or co-ordination will fail and lack of standardisation will cause process failurem, wasted effort, organisational inefficiency etc.

Project/programme dependencies: a large programme of work will often have many implicit or explicit dependencies. Development must be completed before UAT. Partners must be chosen before go-to-market strategic launch. Specialist skills must be hired before project begins. These kind of things are collective project /programme dependencies. Fail to manage these and your plans may go severely awry.

Hopefully these examples give you a flavour of what I mean when I say that architecture is about dependencies.

Managing in the context of dependencies

How about the management part? Well this is really what you need to do with the dependencies. In no particular order, the most important aspects of management in this context are:

Make decisions: As an architect you need to make decisions about dependencies. Should we build our systems to depend on standard X or Y? Should we establish a dependency on an expensive proprietary software component or adopt an open source alternative? Do we build a software application to make a manual business more efficient?

Communicate: no amount of smart architecture work is going to be helpful unless the results of the work are effectively disseminated to where it is needed – and this might mean external to an organisation as well. This requires decisions to be clearly and unambiguous communicated. Your architects had better be good communicators or the effort will be wasted. This might mean codifying architectural details in comprehensive documents but this may also be unnecessary – the point is that the communication is effective and produces the right behaviour as a result, not the format of the communication.

Plan strategically – your dependencies will change over time. If you make a far-sighted strategic plan to move all your software development to Clojure in 5 years, then you will need to plan for it. What dependencies do you need to get in place? Have you got infrastructure teams that can run JVMs in virtualised environments? Have you hired a Clojure guru to envangelise, convert and train all your Java developers? Do you need to create a Clojure library to wrap some legacy APIs / services? Of course, strategic planning of such dependencies implies prioritisation, trade-offs and management of uncertainty. It’s not easy, but it’s one of the most important jobs for an architect – nobody else is likely to have such a comprehensive view on all the relevant factors.

Understand / diagnose – when there are issues, you will frequently need to do some root cause analysis. Again, dependencies provide you the most useful avenue of attack for understanding what is happening. Why is X not working? Because of dependency Y. Why is Y not working? Because of bugs in dependency Z? What are the options to fix / replace dependency Z? And bang – dependencies have led you to a diagnosis and potential solution.

Tips and tricks

Finally some general tips for thinking about architecture:

– On average, depend on as little as possible. Minimal designs are simpler to understand, easier to manage and more flexible to change. In the software arena, this in one of the areas when it’s great to be working with Clojure on the JVM – the only thing you need to depend on is the Java Platform (JVM + Java Runtime Environment), you don’t even have any infrastructure / OS dependencies.

Eliminate unnecessary architectural work by considering whether you are actually managing dependencies. If not it is a sign that either a) the work isn’t adding any value – what use it is if nothing depends on it? or b) the work is local and/or doesn’t have architectural impact – in which case it’s not architecture work and should possibly be de-prioritised / handed over to someone else.

– Make people responsible for their dependencies as well as their own area – it massively aids communication, reinforces good incentives and encourages teamwork if people feel responsible for helping the parts of the organisation / architecture that they depend on succeed. There should be no excuse for “passing the buck” – if you weren’t managing your dependencies, you weren’t managing at all, full stop.

– Deliver dependencies as a service – in a mirror image of making people responsible for their own dependencies, the provider / manager of a dependency that other parts of the organisation rely on should be seen as a service provider. It’s their job to provide a high quality, cost effective, responsive service that meets the downstream requirements. This doesn’t necessarily mean creating KPIs and SLAs (although you might consider this) – but much more important is the service mindset and commitment – “we’re building the best possible X for our customers/users/colleagues/partners”

This is architecture.

  1. lenand says:

    Nothing wrong with mapping everything with dependencies if you can work without pictures. I can’t. I need blobs and sticks. The original debate in project network analysis was Activity on Arrow, or Activity on Node. Perhaps it is the difference between a coder and a cartographer.

    • mikera7 says:

      Well there’s certainly nothing to stop you using blobs and sticks to *communicate* the dependencies. I’m of the view that you should use whatever tool / visualisation technique works best for the task at hand.

      As for activity on arrow vs. activity on node – aren’t they equivalent?

      • Pferdy says:

        Yes, they produce the same answer – but they look different. Different drawing conventions (aka standards).

        Being a Node Person , I gravitate to Things and Links having a different nature. An Arrow Person would be happy defining the world in dependencies. Dependencies lead to better visualisation of timelines and “functional flow diagrams”.

Leave a Reply

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

You are commenting using your 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