Capital assets are long-term investments whose ROIs are expected to more than repay their capital. Conventional software components rarely satisfy this definition. A prominent reason is that our industry demands components be used as is, much like physical parts. Yet unlimited malleability is software's greatest asset (and its greatest liability).

In addition to traditional markets for software and content, individuals and firms can also now look to the enormous "commons" of information and software that is openly available. The accompanying Executive Report looks at what's available, discusses how firms might use these goods, and offers some guidelines to bear in mind during the assessment and adoption process.

It cannot be said any plainer: we have significantly underestimated the impact that the Web is having -- and will continue to have -- on our personal and professional lives. Within five years, the Web will become the dominant personal and professional platform for communication, collaboration, entertainment, learning, and all forms of business transaction processing.

Organizations that invest in product and process projects must have a plan for investing in these projects. The human resources needed to staff proposed projects almost always exceed the human resources available. How should an organization decide which projects should be staffed and which shouldn't?

This Executive Report is the second in a four-part series on the outsourcing lifecycle. The series is based on a detailed understanding of the outsourcing experiences of 107 organizations. This report focuses on the first three building blocks — Investigate, Target, and Strategize — of the Architect Phase, which is the first of the four phases of the outsourcing lifecycle. The information here provides the strategic information you need to ensure the entire lifecycle works well.

Despite the promises of service-oriented architecture (SOA), many organizations are increasingly encountering difficult governance issues as they start to ramp up their early SOA efforts.

Operational technology will persist with hierarchical management structures, centralization, and standardization -- though the sourcing of infrastructure will change dramatically through "X as a service" delivery models, open source software (OSS), and thin-client architectures, among other infrastructure opportunities.

Recently, problems with service-oriented architecture (SOA) projects have been the focus of some public statements, ranging from one saying that 50% of SOA projects are a complete failure to reporting rage over the changes instituted as part of SOA projects. These seem to report a pretty dismal scenario. But is it reality?

Cloud computing has become the accepted name for the next evolutionary step of the data center and the services enabled by that infrastructure. It encompasses a range of service capabilities that can be provided to the enterprise and to individuals through a utility computing model by using multiple processors that are managed together as one, with access to services, provisioning, and management through the Internet.

As you may have noticed, the current economic environment is causing people to behave differently. This stressful climate has likely changed the tenor of your negotiations by either making it easier for you to get what you want or making it near impossible to achieve your goals.

The term "service-oriented architecture" (SOA) covers a wide range of definitions, applications, and approaches to implementation. A broad view of SOA encompasses business services, enterprise agility, and business transformation. A more restricted view treats it as the application and technology architectures, which limits its scope to strictly an IT concept.

The software engineering practice is merely half a century old, but a great deal of development has occurred in this relatively short time. It is interesting to notice that as systems have gradually become more complex, sophisticated, and larger, code has become more efficient (e.g., more functionality per line of code), and software development methodologies have tended to become leaner and more agile.

Studies of workers in the IT sector continually show large variations in the capabilities of individual staff members.

Business capabilities are fast emerging as a challenge to the traditional mindset of the business process. Both business architecture and software development methodologies are increasingly embracing business capabilities, which are heralded as an important breakthrough in business-IT alignment. How much truth is there in these claims?

Like electrical service, computing has now become a utility. You can draw on your required computing resources -- hardware, software, storage, applications, and infrastructure -- when and where you need them and in the amount you need.

Systems development, business analysis, and project management are now very mature, as are the lifecycles that support them. We have Scrum, RUP, Feature-Driven Development (FDD), and several others.

The accompanying Executive Report begins with a brief overview of the outsourcing lifecycle and its components to provide you with the necessary context. This first part of the series then looks at seven cases in detail to provide you with insights into how the organizations did or did not apply the lifecycle. These seven cases, representing large, IT-using firms in Australia, volunteered for theoretical sampling, not statistical sampling, in the study to provide generalization validity. The rest of the reports in the series will explain each of the building blocks and related activities of the lifecycle, giving many examples from the 107 cases.

The business intelligence (BI) landscape has changed. New technologies enable more advanced BI applications for users. BI is no longer limited to an exclusive group of executives and analysts. Today's decision makers, from executives to frontline customer service representatives, need BI for decision support. BI is no longer just for strategic and tactical planning. Operational and near-real-time BI for the masses is the order of the day.

Over the years, I've had a growing suspicion that has turned into a certainty: the success of agile adoption efforts is not based primarily on the practices or even the team. I've come to believe that the number one reason for the success of any agile adoption effort is the individuals involved in the projects.

Identifying risks is an old management activity now reinvigorated within the context of the IT Infrastructure Library (ITIL) service lifecycle, found in ITIL version 3 (ITIL v3).1 Risk identification is the necessary first step to risk mitigation, and a fresh way of looking at risks through the prism of service creation and delivery can heighten not only an understanding of risks, but an awareness of what management actions are required to avoid them.

Cost-cutting, freeing up cash, and generally preserving financial health is the order of the day for companies in our current recession. The IT organization finds itself in a uniquely awkward position. It is expected to pony up savings like every other unit, but can this be accomplished without compromising valuable resources and capabilities needed for the future?

The typical application development team is required to understand and code a great deal of relatively low-level software technology, including event management, transaction integrity, complex GUI frameworks, customization of development tools, configuration of code generators, error management, and logging.

The accompanying Executive Report is the second in a series that describes the adoption of Web 2.0 technologies and the impact they're having in the enterprise.