I listened to a podcast a while back, can't quite remember which, where they were talking to a company that had started with internal blogging. The idea was that all staff got their own blog to write on and were encourage to do so whenever they had an idea or something else they felt could be interesting to share with others in the team, or across the teams. I didn't pay much attention to it at the time though, just though it a bit over the top to be honest. But today it kind of struck me that actually, it's a really good idea.
When everyone is busy with their tasks at hand ever so often someone gets an idea or finds something in their day to day work annoying but at the time there aren't really any forum to communicate this to fellow colleagues so it gets forgotten. Instead this can be captured in a blog post. This will allow for the idea or frustration to be available to others as well as the poster for later when it may come in handy. And as for frustrations in day to day tasks, if enough people find that they share the same frustration this is the point where it's time to do something about it.
So the long and short of it is that it's probably a really good idea to encourage an internal blogging culture in order to identify all the potentially lost opportunities for improvement that disappears in our day to day work.
During the Øredev conference we talked around the drivers for SOA. It then struck me that most common drivers for a SOA initiative is a large enterprise that is trying to align their business goals as well as cutting IT costs (or at least that is the organisation described in most texts and discussions). During my work however I have found two other interesting drivers for SOA initiatives.
We are currently working with an organisation who have had a single monolithic system written and owned by one provider. The relationship with this provider have not been that easy and the quality of the system has been poor at times. This have highlighted the need to be able to spread the risks amongst several vendors. The services the organisation is in need of will need to be highly specialised so they will not be able to buy any modules of the shelf. SOA will still provide them with the opportunity to invite several vendors that can each create the services they are most suited to create. This will spread the risks and make it possible for them to change provider of a service if the quality or relationship goes bad with another.
In my previous position as an architect with ProcServe we started an initiative to SOA aline the software that is used to deliver the service ProcServe provides. The main drivers for this were two. ProcServe is a service company, making money by delivering an e-procurement solution that will help the customers to save money in the organisation. The software stack is built on both Microsoft .Net and Java technology as well as using several COTS products. We needed to provide a simple way for all the applications to integrate as well as making it possible to reuse as much as possible so SOA was a natural choice from a purely technical standpoint. This also aligned well with business need to make it possible to deliver functionality into customers back-end systems and portals. The SOA stack that we built made it easy to expose services to customers as they were needed.
The above examples shows other strong drivers for SOA initiatives that are not often discussed. The first example is inspiring in that it mitigates risks that many larger organisations are suffering from if they have been unlucky enough to buy into a technology stack that soon after fails or where the provider goes out of business. SOA provides a very real way to remove such risks and could also make it a more level play field for large and small vendors. This is especially true in the public sector.
The second example is every technologists dream. The driver is a purely technical one where the need is elegance and simplicity. The fact that it is later discovered to be a way to help the business expand and a way to serve customer better make it even better.