Coding the Architecture - security tag

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?

NFRs for system replacements

Wed, 28 May 2008 10:35:00 GMT

As software architects, we tend to write about non-functional requirements a lot; particularly about how they should be defined and challenged because of the influence they have. One of the reasons for talking about NFRs a lot is that, in the majority, project teams don't give them the attention that they should. And here's a great example that's slightly different from the story where none of the NFRs were defined.

As is the case in most organisations, technology has a limited lifespan. Perhaps the business evolves, the technology becomes harder to maintain, etc. Whatever the reason, many organisations regularly look at replacing their existing systems with solutions that are shinier and more buzzword compliant.

In one of these cases, an organisation put together a 125 page specification for the replacement system detailing exactly what the system should do along with some details of the non-functional requirements. However, out of those 125 pages, only 1 of them featured the NFRs, and they can be summarised as follows.

Performance : the system must be fast.
Scalability : the system must be able to support 100 messages per second.
Availability : the system must be available 24x7.
Security : only certain individuals are permitted to access the system.

Credit where credit is due ... at least some thought was put into the non-functional requirements and conversations to explore those requirements aren't starting from scratch. But on the other hand, those requirements are meaningless!

I want to end this post on a positive note, so let me contrast this story with another replacement project that I've been involved with recently. In this instance, the team *had* thought about the non-functional requirements and had detailed definitions for what they should be. This is excellent, particularly considering that the non-functional requirements surrounding the current implementation are vague in nature. System replacements are an opportunity to revisit what's important, and that includes the non-functional aspects too.

Elastic computing

Thu, 01 May 2008 11:01:00 GMT

We had an internal technology session last night and I was on a panel where each of us was asked to come up with the IT aspects of an enterprise architecture for a small (100 people) financial services organisation. My approach was based upon building up a service-oriented architecture (SOA) and then deploying it onto the cloud, which can then scale with the business.

Elastic computing makes a lot of sense in this context for several reasons, but the primary one is that information technology probably isn't (and arguably shouldn't be) the core focus of most small organisations. In other words, take advantage of software as a service, and have that scale with your business by dumping it on the cloud.

While some businesses are using this approach, there are some "interesting" questions to be answered about cloud computing before I think I'd actually propose it for some types of business. First off, there's data privacy and security. I don't want my data on the cloud and I'm sure that many businesses feel the same way. Additionally, there are some other issues around compliance and interoperability (see Cloud computing hysteria paralyzed by bolt of reality for more details on this).

Cloud computing might not be feasible for some applications at the moment, but it is another approach for us as architects to evaluate.

^{"King Cloud" photo by akakumo.}

High-Assurance Design

Wed, 18 Jan 2006 20:11:09 GMT

This week, Cliff Berg is doing a promotion of his latest book entitled High-Assurance Design : Architecting Secure and Reliable Enterprise Applications. I'm sure you've encountered this yourself, but on many projects there's often a disconnect between the development team that build the software and the security experts that reside elsewhere in the organisation. I've certainly seen this happen and due to the different skillsets involved, it's hard to get these two groups of people talking the same language. As a result, security is often inadequately implemented and reliability ... well that sometimes doesn't even feature.

If this sounds familiar then Cliff's book might be for you. Stop by the OO, Patterns, UML and Refactoring at the JavaRanch Saloon to see the discussion and have the chance to win a copy.