Options

They represent trade-offs and sacrifices

A recent consulting engagement has involved me defining a system architecture to solve a particular business problem. While coming up with something that meets the functional and non-functional requirements can be hard in itself, you always have to bear in mind there are always alternatives. In essence, you'll probably come up with several options, regardless of whether you present them all.

The key thing that really struck me recently is that options can vary quite dramatically when you start to think about some of the additional constraints and trade-offs that can be/need to be considered. For example, your "ideal" architecture might be a distributed n-tier system but an alternative architecture might be a simple desktop application if infrastructure simply isn't available. Likewise, if time-to-market is the critical factor, you might even find yourself going down a number of different routes, some of which might be highly tactical and some might involve the use of an off-the-shelf product. Other important aspects might include existing vendor relationships, in-house skillsets, functional scope, non-functional scope, etc.

Whatever options you come up with, whoever is making the final decision needs to have as much data available in order to make the most informed decision possible. Unless you really are spoilt for choice, options represent trade-offs and sacrifices. If you know what these are, you have a much better chance of choosing the right option.

About the author

Simon is an independent consultant specializing in software architecture, and the author of Software Architecture for Developers (a developer-friendly guide to software architecture, technical leadership and the balance with agility). He’s also the creator of the C4 software architecture model and the founder of Structurizr, which is a collection of open source and commercial tooling to help software teams visualise, document and explore their software architecture.

You can find Simon on Twitter at @simonbrown ... see simonbrown.je for information about his speaking schedule, videos from past conferences and software architecture training.



Re: Options

Simon,
First of all I must say this is a nice post with some good advise for up growing architects like me. Still I have to ask. What do you mean by "non-functional requirements" ?

I'm not English native so perhaps that made it difficult for me to put it in right context. Could clarify it bit more please.

Re: Options

Thanks and yes, let me expand. By non-functional requirements, I mean things like performance, scalability, availability, reliability, security, cost, technology constraints, etc. These are all things you need to consider as an architect when designing a solution, but they might not necessarily be related to the functionality provided by the solution. Wikipedia has a good list with many more examples.

Re: Options

Thank you for expanding up on my question. It was more logical than I thought.

How much of the non functional requirements are actually in hands of the architect? I don't think cost is something the architect has to take in consideration, or I'm I wrong here?

Re: Options

I'd say that as an architect you're responsible for all of the non-functional requirements. Of course, there are different ways to satisfy the non-functional requirements and that's where the trade-offs come into play. Of course, trade-offs have cost implications, some of which will be positive.

Re: Options

The architect might not be responsible for defining the non-functional requirements, but they're definitely responsible for fulfilling them. For example, the security policy might be determined by law or third-party requirements but it is the architect's responsibility to ensure that it is met by the system/application. Similarly, if you choose a technology that exceeds the project's budget then that's your mistake.

As for options, I think you've got to be careful about presenting "all the data". As a technical authority you should be able to make many of the decisions yourself based on knowledge of the technology, environment and technical strategy. Rather than presenting a series of options I'd consider asking a series of questions to whittle the options down first.

Re: Options

Defining the non-functional requirements : Very true, although there are cases where you might actually do this (I'll save that for another blog entry).

Options : In the case where you're *the* architect on a project, I agree, you should whittle down the options yourself and make sure you have enough evidence to support that decision when you are questioned about it later (which always happens in my experience!). Having said that, if you're in much more of a consultative capacity, you might not be the one that needs to make the decision, so presenting all of the data becomes necessary. It all comes down to whether you have the responsibility and the authority. In my case, I had neither.

Designing the tactical solution

In my previous post I asserted that there's really no such thing as a tactical solution, but what should you do if you are asked to design one? Before I answer that, let's summarise what a tactical solution is all about.

Add a comment Send a TrackBack