I was just going through some old notes from last year’s Australian Architecture Forum. One of the presenters spoke about how service registries are very useful, but often will end up out of date with the real running systems due to the maintenance overhead. The suggestion was to harvest information from various sources, such as:
- version control
- continuous integration servers
- interface documentation
- task / issue tracking systems
- application servers and message broker
I’ll be looking for ways to add these to the governance toolkit, as regardless how many rules we put in place, people will always find ways around them, often for what sounds like good reason (so they don’t tell you!)
August 30, 2009
Zapthink remind us of the value of reference architectures.
The Ujuzi take (with apologies):
- build on a pre-existing reference architecture where possible (this is the standing on the shoulders of giants bit)
- if you are committed to a vendor’s product, decide how deeply you are prepared to entrench it in your architecture and then build on their best practices for the chosen bits
- maintain a register of lessons learned (and solutions) as you go through projects
- document antipatterns and how to avoid them
- document new patterns and how to apply them
- document what doesn’t work as advertised – whether it is a vendor product capability or just an architectural approach
- PoC, PoC, PoC
August 19, 2009
http://blog.springsource.com/2009/08/10/springsource-chapter-two/
This is going to change the game in a big way – Oracle et al, look out!
August 12, 2009
Faith without works (james 2:20) is plain trouble and so is architecture that’s not backed by a PoC.
August 7, 2009
Over the last year or so, I have been leading an SOA initiative which by all accounts has gone relatively well, with one downside. All the developers and architects will give it a qualified thumbs up (hopefully not just because it’s good resume fodder), but the business analysts and business owners of the applications that are enabled by our beautiful service catalog, have no appreciation of what the services are and how they affect them. The only exception from this is services that we expose to our customers as web services.
So how do we ‘take SOA to the business’ – and more importantly, why should we?
The recent release of TOGAF 9, which includes a chapter on SOA has made it clearer. Basically, we have been doing developer-led SOA (or for the sake of my ego, architect-led SOA), building little-S services that are important building blocks for the techies, but the business couldn’t care less about. Ironically, the highly resuseable services that the developers love are probably the ones that are least meaningful to the business (future post on this). In order to ‘take SOA to the business’, we need to think of the entire business as a set of capabilities that we provide to customers through a combination of people, process and technology. These capabilities are big-S services, and are recognisable elements of the business value chain (e.g. assessing a credit card application). Their work has a quantifiable real world effect on the bottom line (as opposed to a technical real world effect such a database table being updated), and similarly their SLAs on performance, availability etc. are traceable to a commitment to a real customer or other business stakeholder.
But wait, there’s more.
ITIL v3 gives us a service-centric framework for managing the lifecycle of IT services, i.e. capabilities provided by IT as the technology contribution to big-S services, and is already well established at the ‘lights-on’ end of the service lifecycle. In my opinion there is no reason why we couldn’t use ITIL as an overarching framework to manage the lifecycle of all big-S services, and then overlay whatever else we need at the lower-level to manage the lifecycle of the little-S services that contribute to a big-S service. As an examlpe, this is where we would see the intersection between the service registry/repository and the CMDB.
So Bill (are there people in my service), I think I might finally be getting it. Now I’m off to re-read the debate on B-SOA vs T-SOA 
Eureka
ps – if you have a southern drawl, replace big-S service with ‘Business service’ and little-S service with ‘Technical service’.
August 4, 2009
Welcome – this blog is about sharing and growing our ujuzi:
- our experience – over 30 years in total in the domains of business process improvement and using technology for business advantage
- our knowledge and expertise – accumulated over time, and ever growing
- our skill and technique - how to put what we know into action
We don’t claim to know it all – far from it – this blog is more about an opportunity to get some good old 360-degree review on what we think we do know!
Enjoy.
August 1, 2009
