Steve's Blog on Rational Requirements and Design
SteveArnold 270000T4JF Tags:  shoring off continuous agile outsourcing uml architecture delivery devoid 3,445 Views
Well it's a new year, and what with the usual new year resolutions - getting fit, learning to play the guitar, and blogging regularly ! - I thought I'd also have a go at that other new year tradition - some technology predictions for 2013!!
As I'm a software engineer, they really come down to an optimistic, and somewhat biased view of some software development trends I've seen in 2012 that I hope will continue in 2013....so here they are:
Continuous deployment becomes common place - I think there is a perfect storm of desire to improve development-operations, improvements in virtualisation/cloud and in the software tools to enhance current build practices to make continuous deployment practical. So I'm looking forward to a year where this starts to become the norm rather than the exception.
Architecture comes back in fashion - a lot of organisations are struggling with agile, and in response to this I'm seeing a lot of teams turning back to doing more architecture and design. They are using the models in a very collaborative way - to communicate how the software works and seek improvements via colleagues' feedback, so that the software is as good as it can be. So 2013 will be the year when architecture cements itself into teams' agile practices.
Software development comes home - Is offshoring development really cheaper and faster? Well from what I've seen, a lot of organisations struggle to get a model that works - and they end up with a waterfall, highly contractual model, which doesn't deliver what they want in a timely fashion. So while there is definitely a place for global delivery and off shoring, it's not the panacea that some organisations thought. So in order to get better visibility, more agility I see more organisations reversing the off shoring trend and growing their software development capability in 2013.
SteveArnold 270000T4JF Tags:  rsa software architect system ea architecture enterprise 1,295 Views
Historically, many organizations develop enterprise and software architectures in isolation from each other, or they try to reconcile them manually. This isolation causes several problems:
By using IBM® Rational® Jazz™ technology (see jazz.net), it is now possible to link elements in an enterprise architecture stored in IBM® Rational® System Architect with model elements stored in IBM® Rational® Software Architect extension for Design Management (sometimes called Design Manager). This capability has several benefits:
If you'd like to see how to set it up - then I recently wrote a developerworks article with Jas Atwal - which walks through the steps, and also shows some of the analysis you can perform once it is set up. The article can be found here.
SteveArnold 270000T4JF Tags:  collaboration uml modelling agile collaborative architecture 1,666 Views
I'm an unashamed modelling fanatic - but in the last few years it's become a topic I'm almost afraid to mention. Why ? Well in the fad focused industry that is IT, modelling (with tools) has become deeply unfashionable. There has been a lot of misunderstanding about why modelling with tools is useful, not least because agile is often misinterpreted as anti-tool ( ofcourse it's not, you still use compilers, editors, src control, continuous integration tools etc). So where does modelling fit, in an iterative/agile world and why do I think it's starting to become popular again?
Well firstly, I tend to think of two broad uses of models -
Modelling for communication and collaboration, and modelling for specification (i.e. Code generation ). Now it's the former that is absolutely vital - even in agile/iterative development.
One of the benefits of agile is that you produce working software regularly - but while this guarantees that the code works, it's still the first version - like the draft of a document. So the question is how do you make the software as good as it can be - so that it delights users - rather than just satisfying a spec ? Well the answer, just like improving the first draft of a document , is that you need to communicate how the software will work, and then collaborate on that with your colleagues to improve it.
Obviously you could write the code, peer review it, and then change it - however this introduces rework and waste. So a better approach is to produce a high level model ( not a detailed specification )showing the key information, not too much detail, but enough information to enable someone to understand the high level approach and offer suggestions for improvement. This kind of modelling takes a few hours - so very possible in a short iteration project - yet still allows for others to comment and suggest improvements before the code is written - resulting in improved software that delights users.
"Im an agilist, and I do agile modelling on a whiteboard" I hear you cry. And if you're in a small colocated team this works perfectly, and exemplifies what I'm talking about. However in my experience, as teams scale and become distributed, they tend to forget about modelling altogether - rather than focusing on it more.
So why now ?? And why do I think modelling is coming back into fashion? Well according to Gartner agile is going though the valley of despair on the hype curve - and in my experience more and more organisations are starting to look at modelling as a possible approach to improve their software delivery.
Secondly the tools around modelling have improved significantly in recent years, transforming modelling tools from single user desktop tools, to collaborative team tools. This is vital as it simplifies modelling as a team, reviewing and commenting - making it possible for this to be very lean and to minimise waste.
So perhaps modelling isn't such an anachronism after all. And given the current trends towards distributing agile, then modelling for collaboration will, I think, become critical for successful projects.