Coding the Architecture

Modifying Open Services

Fri, 14 Nov 2008 19:53:38 GMT

There's been a huge push recently towards service oriented architectures - sharing services within an organisation with benefits such as reuse and making information consistent. Take a simple example such as a catalogue of products for a furniture company. As a shared and open service, all of the companies systems - Sales, Marketing, Support, Delivery and Billing applications - can use this information in an open and consistent way.

If a service is very open and easy to use (e.g. services operating via a RESTful interface) then there is a good chance that applications will use it in a way you didn't originally intend and probably by applications you don't even know about. This sounds great but you'll soon come across the issue that you've lost the ability to audit the current use and gauge the effect of any change. As an example let's say you want to add details for 'forest sustainability' to our furniture information. We add a block of xml to describe this and release. However an application that uses our service starts generating errors as it's not expecting this new information. (We could argue that it shouldn't do this but this is what happens in the real world.) Problems are more likely if you have to modify rather than add to your format. Changing an integer to a floating point number could cause strange issues.

You need to be able to get dependent applications to test with your new service before you release but who's using it and how are they using it? You can log the incoming requests to know what is being used but you don't know who is using it - so how do you know who has to test changes?

This is a problem I've been seeing recently and a solution is to use authentication even if you have no intention of restricting access. You can make the credentials easy to obtain but you need to make sure the users of your service are registered and provide sufficient contact information. Of course, actually getting the users to test and adapt to changes are another issue but at least they can't complain they weren't informed.

Has anyone else seen this issue and what were your solutions? Did you just 'publish and be damned' or end up introducing heavyweight process to control releases?

The role of the Software Architect in successful projects

Thu, 30 Oct 2008 21:26:00 GMT

Admittedly the "Coding the Architecture" audience for this is probably kind of small (hi Dave!), but I'm presenting a session at the Jersey BCS in a few weeks entitled "The role of the Software Architect in successful projects".

The IT industry has a love/hate relationship with the Software Architect role, with many organisations dismissing it because of their negative experiences of architects that dictate from ivory towers and aren't engaged with the actual task of building working software. This reputation is damaging the IT industry and inhibiting project success.

Things need to change. This session looks at some of the reasons why software projects fail and how a hands-on software architect can be invaluable in addressing these issues to drive the project to a successful conclusion. Software architects are here to help, not to hinder.

The session is aimed at anyone undertaking software development projects; including developers, architects and IT managers. It will take place on Thursday the 13th of November 2008, 12:00 in the Ouless Room at Jersey Museum. E-mail jersey.events at bcs.org to reserve your place.

p.s. if this sounds familiar, it's because it is

Becoming more architecturally aware - part 2

Tue, 28 Oct 2008 20:18:49 GMT

Last time I talked about how we need to understand how application frameworks are designed and work behind the scenes in order to produce code that is consistent and compliant with the overall architectural principles. The second aspect that we need to become architecturally aware about is the underlying technology.

Again, let's put this in context of my current .NET project. I have much more Java experience than .NET experience; I've written some C# and I've played with Silverlight, but ASP.NET is new to me. Thankfully, the concepts behind ASP.NET translate fairly directly with those behind JSP, so it's not as if I'm tackling this from a standing start. Having said that, I've felt that it's really important to get to grips with the underlying architecture of the technology so I can be sure that the code I write, again, integrates properly into the overall architecture. An example here would be the ASP.NET page life cycle. Like JSP, ASP.NET pages have a series of things that happen to them when a request is made, which includes creation of the request/response objects, page compilation, page instantiation, calling page event handlers and so on.

Knowing the finer details of a programming language is one thing, although using or not using new language features such as generics isn't necessarily going to negatively affect the architectural integrity of the solution. Not understanding something like the page life cycle of ASP.NET could. For example, it's important to understand the page life cycle so that you understand when objects can be shared/cached. Session management is another important thing to understand, and blindly throwing objects into the user's session can have architectural implications if your application needs to scale horizontally and you need to implement transparent session failover using session replication.

Being more architecturally aware doesn't necessarily mean that you need to understand the entirety of the bigger picture, but you should understand how to write code that is architecturally compliant. And that means understanding more about how the underlying technologies work.