Enterprise Abstraction

Of Requirements

Requirements.  I dislike them.  Mostly because they're usually either

1. so poorly done as to be useless for determining the work to be done and for testing, or
2. so tediously lengthy and detailed that nobody is inclined to use them.

That said, there are many times in life one has to do unpleasant things.  Sometimes requirements are required.

 Therefore, if we must use them, I suggest (read insist) on the following:

• Make your requirements SMART requirements.  That is:  Specific, Measurable, Attainable, Relevant, and (I augment the last one) Testable/Trackable.  In short, if they don't tell you what you need to do, and you can't test them - toss them...  you are wasting everybody's time.
• Have a few requirements as possible, but no fewer.  More requirements definitely does not imply better.  Unless you're dealing with contracts, the purpose is to define the work such that everyone understands, and to be able to later test the work to see if it meets expectations.  Any more than that and you're wasting everybody's time - particularly your own.
• You don't necessarily have to have all the requirements up front.  It's fine to go back and realize you need some adjustments/additions.  That said, be mindful of scope creep. 
• Remember your clients.  Who are your clients for requirements?  In my shop, there are two clients:  The developer (and general project team), and the testers.  Write requirements so that they can do their jobs.

One method I find exceptionally helpful in requirement writing is to use the words "Must, Should, and May" in a very structured manner, as per RFC 2119.  This may seem a bit excessive, but it really helps me control my thinking about what requirements are essential (MUST haves), what would be really nice to have (SHOULD), and what we can have (May - Optional).  It also helps to make the requirement statements clear to everyone - particularly the developers/implementers and testers of the future system.

Rolling stone of governance

My experience with a large library/small organization is that the best you can do when starting architecture is to get the stone rolling in the right direction, and subsequently, and only if absolutely necessary, nudge it from that point forward.  It's impossible to stop the stone (any particular project or initiative) once it's built up some inertia.

We've tried "after the fact" governance processes that were too heavyweight and too late to be effective, no matter how logical or economical our arguements.  My experience is that unless you start projects on a firm footing, there's very little chance of having anything but a limited impact on success of a project post-initiation.

Hence, we've put most of our effort in providing a service to business of helping them construct their proposals and manage the project initiation process.  In some cases we'll initiate projects ourselves.  In other cases, we'll parachute in to offer a prospective project proposer assistance with scoping, tasking and estimating a project early, and most importantly, with improved speed and efficiency as compared with the more traditional method. 

We find that in our practice this reduces uncertainty and eliminates most of the "investigation" projects spawned from fear of not knowing the complete solution up front.  Most importantly, ideas usually manage to move from thought to proposal stage an order of magnitude faster than they had  otherwise.

The biggest challenge thus far has been to have architecture perceived as primarily an enterprise  project management and business-related process than the common view of it as a technology-related process.  This acceptance has proven to be achievable, but it's taken uncounted weeks and months of communication and demonstration to convey. And still the march goes on.

SOA and Agile - effective teams

Steve Jones provides a succinct and rational approach to breaking large projects into smaller, more effective efforts by applying SOA on top of Agile methods.  Essentially he suggests breaking down the components and services as work packages that are able to be completed by a small (4-6 person) team, and managing the work packages. 

A simple, rational, and as he explains, a time-honoured approach.

Development capacity for improvement

Nick Malik brings up a good point regarding the need to have extra - IT driven - capacity to apply purely to the task of simplifying and reducing the complexity and maintenance of systems.  In my experience, nature abhors a vacuum, and it's particularly difficult to have a full team dedicated to reducing complexity, even if you could justify the expense by having the team pay for itself through reduction of costs.

I think it would be particularly important in the establishment of such a team to ensure that it was driven by it's mandate to reduce complexity, and to ensure savings over the long term.  I agree that it would be best to be IT driven, and not driven (directly) by the ongoing business concerns.