This is a follow-up to Designing enhancements, where I briefly talked about how enhancements to existing software systems can benefit from the principles and practices of good software architecture, particularly where interfaces to other systems are involved.

Given the size of the enhancement project, we could have easily decided to deliver the whole lot in one go and in many ways this does seem the obvious thing to do. After all, it's only ~8 weeks of work for 2-3 people with a small scope and a limited complexity. But I decided against this and split the overall project into two distinct time-boxed phases as follows.

1. The modification of one key use case, including integration with the third party end-to-end (happy scenario only, no exceptional scenarios).
2. Delivery of everything else.

It wasn't the business logic associated with the interface between us and the third party that concerned me, nor was it the requirements around security or audit. No, for me, it was the actual connectivity between our application server and the Internet. As I said in the previous post, writing the code to send XML over HTTPS is easy but connecting out to the Internet from the architecture isn't something that's been done before. We knew that we'd need to open up firewall rules on the corporate LAN but this isn't something that I've seen done in this particular environment. For this reason, I wanted to deliver enough of the solution (the architecturally significant bits) to evaluate and prove that the connectivity would work as expected.

We delivered that first phase a couple of weeks ago now and initially the connectivity between the application server and the Internet *didn't* work! Everything was installed correctly and firewalls were configured, but we just couldn't find a direct route out of the network. Despite everybody saying that it wouldn't be a problem, it turned out that we'd need to send the traffic via an existing proxy server, which would only accept authenticated requests. A short while later we had a slightly modified version of our release with the appropriate proxy server configuration enabled and this allowed us to successfully see the outside world.

Although the release didn't go as expected, it was a success because we now have a much better understanding of the constraints placed upon our software architecture by the infrastructure and we found the side-effects much earlier than we would have done by going with a single release. We'd successfully identified the risks with the highest probability of happening and planned for them. Managing technical risk is one of the key aspects of the software architecture role, with early evaluation allowing you to prove that your software will work as expected when released. For new systems or enhancements to existing ones, understanding the big picture can and does contribute to the overall success of projects.

Responses[1]

Posted by Simon Brown on 01 March 2010 20:10:06 GMT #

Whenever we talk about software architecture, undoubtedly we'll end up talking about the "big picture", but what exactly does this mean?

Read the full essay...

Add a comment

Posted by Simon Brown on 24 February 2010 21:26:00 GMT #

We're enhancing one of the software systems that I'm involved with, where we're adding new functionality into some of the existing use cases. If you imagine that these use cases are implemented by the users working through a number of pages in a web application, we're basically modifying the final step across a number of them.

So then, the system is being modified from the user's perspective because they are going to see some changes in the way that they use the system. While this itself isn't architecturally significant, we are interfacing with a brand new system behind the scenes. Typically, system enhancement projects require a very light architecture touch but this one needs slightly more because of the nature of it.

Interfaces are usually one of the more risky elements of software projects, particularly when you're consuming an interface that you don't have control of, as is the case here. Furthermore we're doing something that hasn't been done in the existing architecture, which is interfacing with a third party over the Internet. From a coding perspective it's easy because we're just opening up a HTTPS connection and throwing some XML data down it. Where it starts to get tricky though is with our deployment infrastructure because our servers need to punch through the firewalls to reach the outside world.

Although an enhancement to an existing system, this is one of those projects that benefits from some architectural input. Rather than dive straight into the code, it's important that somebody steps back to look at the bigger picture elements such as:

• Design and how best to integrate the new functionality.
• The definition of the interface and whether it's synchronous or asynchronous, the protocol, the message format, etc.
• Confidentiality of sensitive user information and ensuring service credentials remain secure after deployment.
• How the changes affect the existing infrastructure from a security perspective.
• How the new functionality will meet existing audit requirements.

This is no different from what you'd do at the start of a software project, but it highlights that architecture is often necessary at other stages during a system's lifetime. Next time I'll discuss how we phased the delivery of this enhancement to evaluate our architectural decisions early.

Add a comment

Posted by Simon Brown on 22 February 2010 22:06:17 GMT #

The line between software development and software architecture is a tricky one. Some people will tell you that it doesn't exist and that architecture is simply an extension of the design process undertaken by developers. Others will make out it's a massive gaping chasm that can only be crossed by lofty developers who believe you must always abstract your abstractions and not get bogged down by those pesky implementation details. As always, there's a pragmatic balance somewhere in the middle, but it does raise the interesting question of how you move from one to the other.

Read more...

Add a comment

Posted by Simon Brown on 09 February 2010 15:15:23 GMT #

You may have seen this on Matt Deacon's blog already ... I'm running a session for the IASA UK chapter on the 9th of March in London.

Where do you start?

One of the hardest things about software development is being asked to come up with a design when all you're given is a set of requirements and a blank sheet of paper. Many software teams will dive straight into the code and while this can initially be very productive, the slippery slope of constant refactoring is awaiting those teams that haven't quite found a design that works. Often, a little forethought is all that's needed to get the development process heading in the right direction. So where do you start?

This session will answer this question, presenting some simple techniques for tackling software architecture while dispelling the myths about the need for complex tools and big design up front.

I'm planning the content for this session at the moment and it's going to be a mix of presentation, discussion and probably some group work to get you all drawing a few boxes and lines. We're going to cover a very very quick overview of what software architecture is all about before moving on to see what drives and influences it. Once this is done, we'll look at how to actually design software from a blank sheet of paper, focussing on some techniques to help you determine what components you need and how best to organise them. A nice side effect of the techniques we'll use to define architecture is that they can also be used to share architecture, so we'll wrap up by looking at how to document software architectures in a simple yet effective way.

You can find more information about this event and register here. I'm really looking forward to it and hope to see you there.

Add a comment

Posted by Simon Brown on 03 February 2010 09:42:45 GMT #

I'm currently involved in a project to upgrade a third party piece of software and it's apparent that when the software was originally designed, the upgrade process was not considered. This became obvious when we totaled up the time required to perform, configure and post-release test the upgrade - it came to over three days of work. This was not even taking into account any rollback times (which is fortunately simplified these days by the use of virtualisation).

The software is used heavily from Monday to Friday so we wanted to upgrade over a weekend. The vendor suggested we perform an upgrade on a parallel system and then get the users to re-enter all the data into the new system that was missed - you can imagine how well that would have gone down. This would also mean trying to post-release, regression test two systems that are live, being used and not in sync.

Software almost always needs updating/upgrading (unless it's control software for a deep space probe!) The ability and consequence of upgrading should be considered as part of the design and development process. Questions to ask include:

• Can an upgrade be performed in parallel to a live, running system and how does a switchover occur?
• Will a system need to be taken down for any upgrades and for how long? How does this affect your Service Level Agreements?
• How easy will any upgrade be to rollback? Errors occur!
• Can you upgrade parts of the systems or does everything have to be done at once?
• What is the effect on any users? Will they need to log out first etc? Will they lose any work if they fail to follow your procedures?
• How easy will it be to test the upgraded system to determine success? Your notice of failure shouldn't be an angry user phone call.

Some simple tools can make all the difference. Most of my work is on financial applications and I like to run regression reports between systems for important points e.g. End-of-year. However it's often very difficult to get data out of systems to perform simple comparisons!

Sensible configuration management is often missing. If I've upgraded and configured new features in my pre-production environment I really shouldn't have to repeat the process from scratch in production. Manual processes are prone to errors and ideally once I've prepared for an upgrade I should just hit a 'go' button and sit back.

In my experience very few software developers are aware of IT Service Management (ITSM/ITIL). In particular we should be aware of the Change Management, Release Management and Configuration Management roles that support staff have. If you want to read about ITSM/ITIL then the wiki page is a good place to start.

Some of the processes of ITSM may strike agile developers as being heavy-weight but this doesn't stop you developing the system in an agile manner, it just means that it can be deployed within a formal environment.

An architect should be aware of how the software fits into the organisation. So remember that your ‘users’ aren't just the end users but also the support staff who'll be maintaining your system for the next ten years!

Responses[3]

Posted by Robert Annett on 29 January 2010 13:04:00 GMT #

Sergey Mikhanov has written a blog entry called Why I don't believe in software architects that, along with the follow-up comments, makes for a good read. It discusses some of the ways that software architecture is typically viewed (e.g. models rather than code) along with some thoughts about how coding should be included as a part of the role. Since this site is called "Coding the Architecture" and role of a software architect talks about how coding should play a part, I'm not going to dwell on that particular aspect. What I do like about Sergey's blog entry is that it highlights the often familiar (yet rarely discussed) tension between software architects and their employer.

What about career path then? Well, I can't give any personal advice here except for the "avoid advertised 'software architect' positions". The best company will allow you to keep writing code while expanding your area of influence wider and wider into the company products at the same time. This is what really software architecture is about.

I've been fortunate in that I've retained a large hands-on element as a part of my role and I've written code on most of the development projects that I've been involved in. I'm a firm believer that you're in control of creating your own opportunities and that the reason I've remained hands-on comes down to expressing that it's a crucial part of the role. For me it's simple ... coding is essential when designing software because I need to keep my skills up to date and understand that what I'm designing will work. Plus, it's fun and I'm not worried about admitting it.

Unfortunately many organisations seem to think that coding is the easy part of the software development process, which is why they see an opportunity to save some money and let somebody else do it. They view cutting code as low-value. Tension therefore arises because there's a disconnect between the seniority of the software architect in the organisation and the low-value associated with the coding activities.

In my experience, this doesn't happen in small organisations because everybody usually has to get involved in whatever is needed. No, it's those larger organisations where the tension is greatest. I spent some time working for a medium size consulting firm where my job grade put me squarely inline with the management and heads of business units, yet I still used to write code. In some ways it was quite an achievement to be graded as a manager and write code on a daily basis, yet it often felt very uncomfortable as other managers would try to push my name into boxes on the organisational chart.

Being in this situation is tricky and only you can get yourself out of it. A number of developers/architects have been in touch to say that they've found my Why software projects fail presentation really useful as a basis for expressing to their organisations what they would like their role to be. The role of a hands-on software architect discusses the same thing in a shorter format and both have been used as the basis for "terms of reference" for software architecture roles in organisations. Whether you're in an organisation where this is happening or you're looking to move on, be clear about how you view the role of a software architect and be prepared to stand your ground.

Add a comment

Posted by Simon Brown on 27 January 2010 23:25:40 GMT #

Onwards then. The plan for 2010 is simple ... more content about pragmatic software architecture and more training. I particularly want to tackle the practical side of the software design process, including how to approach software design given a blank sheet of paper. We already have a body of material about this on the site and in the training course, but I want to consolidate it further with a very simple set of techniques to use for those "where do I start?" moments. I don't want to create an "architecture process", no, just a small collection of techniques that you can pull out of your toolbox when the time is right.

The other thing that I want to do is publish some sample software architecture documents. We have software architecture document guidelines but I've had a *lot* of requests for some concrete examples. This will go nicely hand-in-hand with the content above to form a great pack of guidance for anybody tackling software design.

Finally, Kevin and I are speaking at some events in the first few months of this year, with a view to lining some more up too.

Kevin and I will be running two sessions at QCon London 2010. The first is one-day version of our training course, while Kevin will also be talking about OSGi and industrial-strength Swing.

I'll be speaking at DevWeek 2010 in London, presenting two talks about improving software quality (automated builds in .NET and load testing).

I'm really looking to the year ahead, helping more people broaden their software development careers and build better software. If there's anything that you'd particularly like to see us cover, please feel free to get in touch.

Add a comment

Posted by Simon Brown on 08 January 2010 10:18:03 GMT #

My final highlight from 2009 is that we improved our Software Architecture for Developers training course by restructuring it and adding more content. We've run this course for several hundred people now and the feedback is consistently excellent. Predominantly it's software developers that attend the course although the amount of existing software architecture experience varies wildly; from people in a pure development role through to others that have done some software architecture/design before. Despite the differing levels of experience, feedback says that the course consolidates existing knowledge and provides clear pragmatic advice on how to actually tackle software architecture and design. We cut through buzzwords and industry fashions, instead taking a common-sense and no-nonsense approach to software design.

I'd say that the majority of people attending the course do have an understanding of their role in the organisation that they work for, although often that same view isn't always shared by everybody in their team. Our discussion of the software architecture role provides some very clear guidelines around this and, again, it's something that people really value because they can use it to help them shape their own role and responsibilities.

One of the things that prompted the enhancements to the course is that we've seen how people often struggle when it comes to tackling software design from a big picture perspective. I've seen this during my consulting work but it's also often apparent during the case study exercise where we provide a set of requirements and ask people to spend about half a day designing a software system. It sounds easy when you see the requirements, but in reality it's easier to get caught up in too much or too little detail. The former sees people thinking too much about the code while the latter sees the system designed as a single box on a sheet of paper. Successful software design needs a balance of both and understanding this is exactly what the case study exercise is all about. It's also worth pointing out that the same techniques can be used when dealing with major system enhancements, so it's not all about greenfield software design.

The course has evolved a great deal over the past year and what we have now really does provide a very rounded, balanced and pragmatic view of software architecture. If you're tasked with designing software and aren't sure where to start, this could be the course for you. It doesn't seem to be the done thing for training providers, but I've published a preview of the course slides to give a feel for the content we cover and to illustrate that we have a very different approach to your regular slide-driven training courses. With only 146 slides over two days, you aren't going to get death by PowerPoint here!

In part 4 we'll look forward to 2010 and outline some of our plans.

Add a comment

Posted by Simon Brown on 07 January 2010 08:51:58 GMT #

In addition to the new content, 2009 saw us present at a number of conferences and events over the year, with all of the slides being able to download and view online. Here are some highlights.

• Documenting your software architecture - why and how?: This presentation was about why you should document your software architecture and how to do it. It complements our software architecture document guidelines.
• Broadening the T: This presentation covered the skills needed by hands-on software architects; including seeing the big picture, dealing with non-functional requirements, using patterns at the architecture level, testing architectures, monitoring and diagnosing performance problems.
• Pitfalls for new software architects: As it says on the tin ... what should you watch out for as a software architect?
• From developer to architect: This is our one-day tutorial session that provides a whistle-stop tour of software architecture. It's basically a stripped down and older version of our recently enhanced two-day training course.

Stay tuned for details of our 2010 presentation schedule.

Add a comment

Posted by Simon Brown on 06 January 2010 08:18:00 GMT #