Does Architecture Matter Any More?

Peter Cripps architecture , , ,

I’ve been reading up on the whole cloud/mashups/social computing thing and the above question occurred to me. Within the context of what are essentially several new architectural styles what is the role of the architect in all of this and what exactly is the architecture he or she is trying to create? In attempting to answer this question my mind diverted to an IT architecture course that I have been lucky enough to teach on a number of occasions both inside and outside IBM. The course is called Architectural Thinking. I imagine (hope) that some people reading this will have attended that class and it occurred to me just how clever the people that created the first version of that class back in 1999 were. The key word of course is thinking. It’s not a class about a particular style of architecture, about a particular architectural process and is certainly (thankfully) not about any particular technology. The key part of that class is about how to think about problems and create architectures, often using an existing style or pattern, to come up with solutions to a client’s business problem. The main axiom being that the architecture should drive the technology and not the other way round. In other words it’s about the fundamentals that never go out of style or, to paraphrase Grady Booch:

Architectural styles come and go but the enduring fundamentals (crisp abstractions; clear separation of concerns; balanced distribution of responsibilities; simplicity) endure and never go out of style.

This course is available outside of IBM for clients so if anyone is interested in running the class get in touch with me on here.

Architecture for a New Decade

Peter Cripps architecture , , , , ,

Predicting the future, even 12 months ahead, is a notoriously tricky past-time. Arthur C. Clarke the English scientist and science fiction writer who sadly died in March 2008 said:

If we have learned one thing from the history of invention and discovery, it is that, in the long run – and often in the short one – the most daring prophecies seem laughably conservative.

As we move into a new year and a new decade the world, in my memory at least, has never seemed a more uncertain place. As the doom and gloom merchants predict an even more troubled economy and the ongoing threats from global warming, increasing pressure on dwindling natural resources and yet more wars do not make for a happy start to 2010.

Whilst solving these truly wicked problems is slightly beyond me I am left to wonder what this new year brings for us architects. According to Gartner the top 10 strategic technologies for 2010 include a number of things which we as an architect community need to be getting our heads around . Of the list of ten, there are three technologies in particular that interest me:

  • Cloud Computing
  • Advanced Analytics
  • Social Social Computing

Whilst it is easy to get consumed by the technology that these new architectural “styles” bring to the table I think the key things we as architects need to do is:

  1. Gain sufficient understanding of these architectural styles to be able to articulate their benefits (and of course their risks) to clients.
  2. Understand what the real difference between these technologies and the one that went before it are so we can build solutions that take advantage of these differences rather than more of the “same-old-architecture” in a slightly different guise.
  3. Figure out how we sell these benefits to the really important stakeholders (the RIS’s).

I reckon that in 2010 being able to identify the RIS’s and convincing them of the business benefits of going with solutions based on technology X is going to be the absolute number one priority. Most businesses in 2010 are going to be struggling to survive and not thinking about IT spends. However survival needs businesses to be both agile and also have the ability to swallow less fortunate companies as efficiently and quickly as possible. Thankfully I think the really good architects that can do this and span the business-IT gap will still be around this time next year. I’m not sure about the rest though?

Five Tips for Finding Non-Functional Requirements

Peter Cripps architecture

Following on from my previous blog on the challenge of capturing non-functional requirements here are five tips for smoothing that process. These have been worked out through some often painful project experiences and, I hope, will avoid you making some of the mistakes I have seen made in the past if these are not considered.

  1. Really, really think about who your stakeholders are. The process of gathering non-functional requirements should begin with creating a list of the different stakeholders (that is, the people who have an interest or concern in the system under development). These are not just the people who will actually be using the system but also the ones who will be operating it, maintaining it, ensuring it is secure and so on). One of the commonest mistakes I observe is that a key stakeholder is forgotten about until the very end of the project (sometimes just before the system is about to go live ) and a critical NFR is not accounted for.
  2. Consider non-functional and functional requirements together. Some NFRs should be associated directly with functional requirements so need to be considered at the same time. For example discussions about response times (the system must provide a new account number in less than two seconds) are clearly related to the (functional) requirement for opening a new account. It is useful therefore to make sure NFRs are considered at the same time as functional requirements are gathered (otherwise you’re just going to go back and ask questions of the same stakeholders again).
  3. Be an “NFR evangelist”. NFRs seem to be one of those project artefacts which no one wants to own. If this is the case on your project then be that person. Read up and understand the importance of NFRs. Create checklists of the kind of NFRs that need to be gathered. Be ready and prepared to present to users and management alike the importance of NFRs. Have a list of anecdotes at the ready that illustrate the importance of NFRs.
  4. Realise once round the block won’t be enough. Despite your best efforts at understanding stakeholders and looking for NFRs at the time you gather functional requirements there will always be some things that are simply not known early on in the project. It’s not always known what external regulations need to be conformed to early on for example or even what detailed availability or performance requirements are needed. I favour a breadth-first approach here. Make sure that early on you at least capture the categories of NFR (performance, security, regulatory etc) together with the key requirements in each category. Later you can capture missing detail.
  5. Be prepared to challenge peoples prejudices and unreasonableness. Believe it or not some people ask for things which aren’t as reasonable as they might be? 24X7 availability, sub-second response times are typical. Whilst it may be possible to build systems that support such NFRs the cost will probably be prohibitive. Be prepared therefore to challenge such requests and offer alternatives, or at least spell out what the costs will be.

Clearly there is more to gathering and analysing NFRs than is stated here however these are some of the considerations you might want to think about and use to start the process if you find yourself on a project where you are the one who is responsible for this.

The Challenge of Capturing Non-Functional Requirements

Peter Cripps architecture

Two of my most recent engagements have been working with clients on defining the non-functional requirements (NFRs) for a new system. It is strange that even now NFRs, and everything about them, is seen as a bit of a black-art. Part of the problem of course is in the very name; who, after all, wants a system to do something that is “non-functional”? Surely we want a system that functions, not one that doesn’t. The problem is also exacerbated by the fact that no one seems quite sure whose job it is to find (gather, elicit or whatever) NFRs. In my next blog I give my five top-tips for dealing with NFRs on a project but first, what exactly are NFRs?Most people who are asked to state the requirements for a new system know how to state what they want it to do, for example:

  • The [banking] system must be able open a new bank account.
  • The [e-commerce] system must be able to send orders to the warehouse.
  • The [social security] system must be able to send a payment to a claimants bank account every two weeks.

These are all examples of functional requirements, they are statements of the functionality we expect from the system. Whether these are expressed as free-text statements, as use cases or as more formal pseudocode type statements they all have the same goal, namely to be a complete and unambiguous statement of what the system is required to do. However there is something missing from these statements. It may be sufficient for the system to open a new account, given the right input data, but how long should it take, a second, a minute, a year? Similarly should the e-commerce system be able to place orders all day and every day or is it allowed to have a break during the evening? Should the social security system be able to send payments to a claimants bank account even if that person is not previously known to the social security department? The functional requirements only really become complete if these additional quality attributes are stated as well. Qualities are one of the things we usually define as being NFRs; in this case the performance, availability and security qualities we expect from our systems respectively.

The other types of thing we usually express as being an NFR are the constraints under which the system must operate. It is very unlikely you will be given complete free reign to develop your system without taking into account some rule, regulation or policy you need to comply with. Examples of these for our three systems above would be country specific banking regulations, XML formats that orders must use or disability regulations that allow all people to use the social security system. Constraints can also include existing systems that your brand-spanking new system must talk to during the course of its operation. The warehouse system in the above example may already exist and be a bit picky about how it receives its orders so unless new orders are provided in the correct format they will be ignored.

Okay, so in summary, NFRs are the quality attributes we expect our system to have and also state the constraints under which our system will be built. Next I’ll take a look at the best way of dealing with NFRs based on some recent (and sometimes painful) experiences.

Wot No Blogging?

Peter Cripps comment

I think I’ve only just realised how much of a commitment keeping a “proper” blog (that is one that doesn’t just regurgitate information discovered elsewhere without adding some additional value or, better still, creating brand new content) takes! I’ve been distracted by other things of late (anyone looking at where I currently work and who is aware of what is happening in the UK economy at present may be able to guess what) however this month I intend to return with, I hope, a vengeance and give myself the target of blogging at least two meaningful, and hopefully of value, entries each month. This one does not count by the way.

Five Tips on How to Think Like a Designer

Peter Cripps Technology

I got this idea from Garr Reynolds blog entry 10 Tips on how to think like a designer. Ten is too large a number for my simple brain so instead I’ve picked the five that I think we as software architects can most learn from the world of design.

  1. Embrace constraints. An architect often complains about the constraints and limitations she has to work under (especially those related to money, time and resource). The skill is to accept constraints and figure out what you can do with the resources you have. After all, a completely unbounded problem with total freedom on how to solve it is likely to end up never being solved. Remember how the NASA engineers managed to fix the Apollo 13 CO2 filter problem using just what they knew was available on the spacecraft. Now that’s embracing constraints.
  2. Practice restraint. This is related to the previous one. As Reynolds says: “any fool can be complicated and add more, it takes discipline of mind and strength of will to make the hard choices about what to include and what to exclude”. As software architects we are often overwhelmed with choice when putting together a solution. There are often many different vendors software products and packages from which to choose and, of course software, by definition, is malleable and can be shaped in many different ways. The trick here then is to practice self-constraint and go for simplicity rather than complexity and cleanness of form rather than clutter and obfuscation.
  3. Check your ego at the door. Ultimately all software, no matter how deeply imbedded or how far it is along the food chain, has an end user to cope with. How that user interacts with and understands the system of which your software is a part depends on how well designed it is. The software architect usually has many different people to deal with (people who use the system directly, people who must maintain the system, people who need to ensure the system is secure, the list goes on). Each of these people has a “stake” in the system (hence the name we some refer to them by as “stakeholders”) and a good architect understands the needs of these stakeholders and is empathetic towards those needs. Empathy is a difficult soft-skill to master but is very important to acquire. It is so important that Dan Pink in his book A Whole New Mind states it as one of the key differentiators that will mark out those people who are able to survive the 21st century world of work where everything is outsourced, commoditised or performed more cheaply by a computer.
  4. Become a master storyteller. You may have just devised the greatest software architecture the world has ever seen but if you cannot sell that solution it’s not going to be any good to anyone and will most likely never see the light. Much software is, by its very nature, complex and describing what it does and what are its benefits can be difficult. Storytelling, that is weaving a story around your system by illustrating it verbally and using multi-media to back up what you are saying can help. Don’t rely on complex and overly-cluttered PowerPoint slides when trying to describe what the system does but instead relate it to everyday experiences your audience are likely to identify with.
  5. Obsess about ideas not tools. As Reynolds says: “tools are important and necessary, but they come and go as better tools come along”. Probably no discipline is more blessed (sic) with tools than ours is. Whilst tools are clearly important to the software architect remember they are a means to an end so don’t sweat over them too much. Instead concentrate on the ideas and use pencils and paper or whiteboards and pens to capture your ideas. These also have the benefits of being readily available and don’t suffer from expired batteries.

Software Architecture Zen?

Peter Cripps architecture ,

Okay so why software architecture zen? According to Wikipedia Zen “…de-emphasizes theoretical knowledge in favor of direct, experiential realization through meditation…”. So, my goal here is the practical application of software architecture, based on my own and others hard earned experiences in both doing and teaching out in the real-world. I got the idea from one of my favorite blogs, Presentation Zen. which is all about creating great presentations based on simplicity and “cleanliness” of design.

For a great exposition on Zen as applied to software architecture see this paper by Philippe Kruchten from 2001. My favorite bit is:

The architect doesn’t talk, she acts.
When this is done,
the team says, “Amazing:
we did it, all by ourselves!”

Two Diagrams all Software Architects Need

Peter Cripps architecture

I’m not a great fan of “architecture by PowerPoint” however there are two diagrams which do lend themselves well to being created using PowerPoint (or any other drawing tool). These happen to be the two diagrams which any architect should have in their back pocket ready to pull out at any time to explain the scope and the structure of their current project. They are the System Context and the Architecture Overview. Both of these diagrams are usually drawn as part of a more complete artefact, which will include a key to the diagrams as well as descriptive text explaining them. However the key part of these artefacts is the diagrams themselves.

The System Context represents the system under development as a single entity and identifies all the interfaces between the system and external entities (i.e. users and other systems).

The Architecture Overview provides an overview of the significant structural, and possibly dynamic, elements of the architecture. It is not meant to be a full specification of the architecture which could be taken by someone and implemented but rather a high level view of the system showing its essential elements. Its main purpose if one of communication, to stakeholders.

The System Context is essentially a “black-box” view of the system under development whilst the architecture overview is a “white-box” view (i.e. showing the major subsystems and components of the system under development. The key thing to remember about a System Context is that it sets the boundary of the system; so everything outside the boundary is presumed to exist already or to be provided by another project. Everything inside the boundary is assumed to be part of the development project that will deliver the new system. The diagram below shows a typical System Context for a new claims processing system. I’ll leave it as an exercise for the reader to envisage what the Architecture Overview for the system might look like (or you could see another example on p195 of this book).

Five Reasons Why Good Photographers Make Good (IT) Architects (or the Other Way Around)

Peter Cripps architecture, comment, creativity ,

In a different life (or maybe even this one, one day) I would have been a photographer and still occasionally dust off my camera to take a few snaps. I recently took to thinking about the traits that IT architects have and decided there were some similarities between them:

  1. A good photographer knows how to use the ideas of others and adapt them accordingly. See here for a wacky adaption of some classic images
  2. A good photographer sees things others don’t by applying interesting or novel views. Here’s an attempt from me:
  3. Photography is both an art and a science. The best photographs come from applying both. See here for a great example.
  4. Don McCullin says “I only use a camera like I use a toothbrush. It does the job.” A good architect knows how to use tools and technology but does not get distracted by them.
  5. You don’t need lots of expensive kit to be a good photographer however when you do want to acquire some shiny new stuff you usually need to convince your sponsor (AKA partner in most cases) of the benefits of the new technology. Architects usually need to convince their sponsor of the business benefits of a new system, not the technical ones. See here for a great exposition of this.

Welcome

Peter Cripps architecture, comment ,

Welcome to my blog. As a start I’ll revive my “five axioms of (IT) architecture” which I came up with a while ago now and which hopefully will have some relevance and usefulness to would be followers of this blog.

  1. Architecture should drive technology, not the other way round.
  2. All architecture is design but not all design is architecture. As blogged by Grady Booch here.
  3. The best architectures are full of patterns. Also stated by Grady Booch, though I’m not sure where.
  4. An architecture should not comprise a single ‘view’, good architectures have many views that satisfy the concerns of multiple stakeholders.
  5. An architecture should be as simple as possible, but no simpler. Paraphrased from Einstein.