Dec

25

A summary of 2007 research on SOA

Filed Under Uncategorized | Leave a Comment

Joe McKendrick wrote an interesting post titled "What the statistics are telling us about SOA" highlighting the numerous surveys and studies around SOA adoption conducted over the last year. Here are the highlights from this year’s studies of SOA:

 

Some interesting reading…

 

Technorati Tags: ,,,,,

Oct

15

Top ten software architecture pitfalls

Filed Under Uncategorized | Leave a Comment

An interesting article by Eoin Woods, on what he considers to be the top ten software architecture mistakes - mistakes that are often learned the hard way through the school of hard knocks!

  1. Scoping Woes - "Many projects end up being doomed to failure before they’ve really started, simply because their scope was wrong. The most common problem is the infamous ’scope creep’ where the scope of the system steadily increases as more and more people get their say…. The converse problem is where scope is artificially limited (perhaps to meet timescales) and so the effectiveness of the system is compromised. Architects need to maintain a particular focus on scope problems that relate to system qualities. Does the system really need to be available 24×7x365? Or would working hours plus Saturday mornings be sufficient? It is really true that no security is needed beyond simple login? Once logged into the system can users really perform any system operation? Catching these mistakes early in the project will help to greatly increase the probability of success."
  2. Not Casting Your Net Widely: "A related mistake that many of us have made is to focus on just a couple of our system stakeholders – classically the acquirer (who is paying for the system) and the end users get all of the attention. However there are often quite a few other interested parties who need to be involved. Consider people like auditors, systems administrators and DBAs, testers, helpdesk staff, the development team and so on."
  3. Just Focusing on Functions: "It goes without saying that a key quality of a system is what it does. People buy or build systems in order to perform useful work and so it’s crucial that the system does what people need it to do. However, a trap that many new software architects fall into is focusing entirely on a system’s functions without considering any of its other properties…. Unfortunately, while we do need to get the system’s functional processing right, this is rarely enough; unless the system exhibits a whole range of qualities (such as performance, security, maintainability and so on) it is unlikely to be successful."
  4. Box and Line Descriptions: "At some point in the development of the system you will need to write something down to explain your ideas for the architecture of the system – in other words, you’ll need an architectural description. … The question is, how do you go about describing something as complex as a modern software intensive system? The approach that we’ve all tried at some point is the single, all inclusive, ‘boxes and lines’ Visio diagram that tries to show everything…. There are two reasons why the huge Visio picture doesn’t work well as an architectural description: firstly, it’s trying to show too much information in a single representation, and secondly, no one is really sure quite what each of the different types of symbol that you’ve drawn mean….. The solution to this problem is to decompose your large diagram into a number of well-defined, non-overlapping views of the system such that each view addresses one aspect of the system structure (such as runtime functional structure, software module structure, data structures or deployment environment)."
  5. Forgetting That It Needs to be Built: "It’s always very satisfying to create and prototype an elegant, sophisticated design for a new system and it’s always more interesting if we manage to use some novel new technologies and techniques along the way. However, when we do this, it’s often worth asking ourselves which stakeholders our new design is really serving – the answer may well be ourselves, first and foremost (and possibly the development team)."
  6. Lack of Platform Precision: "Modern information systems nearly always rely on a fairly sophisticated ‘platform’ of hardware and software to provide them with standard services like a runtime environment, data storage facilities and application security. The platform that information systems use has got a lot more complex in recent years ….This increased complexity has inevitably resulted in a much greater chance of incompatibility between the various components, as there is more to go wrong and more chance of you using a particular combination for the first time. This situation means that its no longer sufficient to simply say that you “need Unix and Oracle” when specifying your platform. You need to be really precise about the specific versions and configurations of each part in order to ensure that you get what you need. This will allow you to avoid the situation where you can’t deploy your system because someone has helpfully upgraded a library for one part of the platform without realising that it means that something else will no longer work."
  7. Making Performance and Scalability Assumptions: "An experience that many software architects will relate to is that of surprises arising during system build and test. This is probably never more the case than when considering performance and scalability – if nothing else because there are just so many things to go wrong! ….. The only real solution to these problems is constant vigilance and assuming nothing! A little performance and scalability paranoia will help you to keep considering these factors throughout the project and to keep challenging your assumptions. Start considering performance and scalability early, create performance models to try to predict key performance metrics and spot bottlenecks and get stuck into some practical proof-of-concept work as your design ideas are forming."
  8. DIY Security: "….This quality is becoming ever more important as systems are exposing interfaces outside the organisation and simultaneously becoming more and more audited due to regulatory factors and corporate governance initiatives. A mistake made in many systems over the years has been to try to add security into the system using “home brew” security technology. Be it custom encryption algorithms, a developer’s own auditing system or an entire DIY access control system, locally developed security solutions are rarely a good idea."
  9. No Disaster Recovery: "Many systems reach production without major mishap and manage to run successfully there for years, without any significant interruption to service. Others aren’t so lucky and suffer some sort of major failure involving entire system recovery a number of times during their operational life. ……The key to getting resources to implement a DR mechanism for your system is to be specific and quantify the cost of system unavailability in a number of realistic scenarios. If you can also estimate the probability of the scenarios occurring then you can use these two figures to convince people that DR is important and to justify a certain level of budget to implement it."
  10. No Backout Plan: "With the best will in the world, things go wrong and while the previous tip is a reminder to ensure production resilience, you also need to remember to allow for disasters during deployment…..Make sure that whatever happens during the deployment of your system or upgrade that you have a documented, reviewed and agreed backout plan to allow you to restore the environment to its state before you started deployment. At least this means that you can undo the damage and avoid total disaster if the worst happens!"

Reflecting on my experience, this seems to be a solid list of pitfalls that are worth keeping in mind when next approaching software architecture.

 

Technorati Tags: , , , , , ,