Enter your email address:

Delivered by FeedBurner

My EA Bookmarks

Misc

Steve's Twitter

    follow me on Twitter

    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.

    Continue reading "Development capacity for improvement" »