I say 'assorted', but all but the last relate to IT efficiencies.
Cost-Conscious Companies Turn to Open-Source Software – BusinessWeek
If you need some examples of Open Source Adoption and an exec friendly article on open source, check this one out. "As the recession puts pressure on tech spending, many companies are turning to open-source software to handle more IT tasks"
Why an Open Source SOA stack makes sense
Speaking of Open Source, Mike Kavis shares his open source SOA stack preference and points out a few others.
elemental links: Open Source Considerations
One more on Open Source. I wrote an open source considerations paper in October 2005. This post excerpts those 'considerations', which practitioners tell me still hold. Folks have incorporated some of these key points into new Open Source strategies for their organizations.
Continuations: Kaizen for Software Development Series
Intro to Kaizen for Development Series, check out the 5 posts to date. "Kaizen means loosely translated continuous improvement. It is a bundle of techniques applied by Japanese manufacturing companies. The goal of Kaizen is to break out of the notion that there is a fixed cost-time-quality tradeoff. Traditional thinking was that if you wanted higher quality it would imply more cost and longer production times. Kaizen posits that with the right process improvements you can get higher quality at lower cost and faster speed."…"I have found that Kaizen practices are also highly applicable to software development. Yet it seems that not that many folks in the software development community are familiar with the tenets and practices of Kaizen. So I am planning to write a series of posts that describes Kaizen principles and how they are applicable to software development."
When "IT Alignment with the Business" Isn't a Buzzword
disciplined approach to cost containment: "Well, let's be careful. First, project costs associated with large business initiatives are only one portion of IT spending. Additionally, cutting costs is easy; you just decrease the services you offer the business. Instead, we wanted to cut costs in ways that would enhance our business alignment, and increase (rather than decrease) the services we offer. To do that, we had to expose all of the costs in IT (PMO and non-PMO) in terms that the business could understand. In other words: business applications. We enumerated all IT budgetary costs by application, and then bucketed them based upon whether they were (1) existing services (i.e. keeping the "true" IT lights on) or (2) new services being installed in 2008. We then launched a theme of "convergence" in IT, which would allow us to converge to fewer technologies/applications that offer the business the same functionality, while increasing the level of service for each offering."
Inside Architecture : Creating a distinction between business services and SOA business services
Nick Malik provides a different perspective. His metamodel varies from mine, but an interesting point-of-view nonetheless. "A business unit may provide zero or more business services. Not all of the capabilities required by a business unit may be involved in a business service. SOA provides the ability to share features. Those features may provide information, or calculations, or data manipulation. They may also include the limited automation of some elements of a business process. SOA services are provided by "installed software""…"The point of this post is to provide sufficient context to challenge the notion that SOA provides shared business services. It does not. SOA provides shared features that many business units call upon. Those features are required by the business processes within those business units."
