What colour is IT?

The IDC estimates that for every dollar spent on IT, 50% is spent on related energy costs.

Source: IDC, Worldwide Server Power and Cooling Expense 2006-2010 Forecast, Doc # 203598, September, 2006.

Certainly a business could spend a truck load of cash on building new, energy efficient data centres with the latest in ambient cooling technology and low power consumption servers. However, the majority of businesses are looking at how to go green with what they already have. Server virtualisation is perhaps the most talked about technique for doing so.

Perhaps it is not immediately obvious, but a Service Orientated Architecture is green. By focusing on the goal of having one set of application assets that effectively and efficiently serve the business needs and using those assets to the fullest, one is reducing computational and IT asset waste. Moreover, as the level of seamless integration with loose coupling grows, there will be some systems, or components of systems that are identified as surplus to requirements. As in, the Currency Transaction Report system is no longer required, because the logic is part of the customer initiated financial transaction orchestration.

Some other quick solutions to reducing costs are:

Duplex printing. The maths is fairly straight forward, but if one has to print something, printing on both sides of paper nearly halves the amount of paper used.
Turn off the desktop PC and monitors. Leaving desktop PCs running when not in use is a big waste of energy, the power saving mode is not nearly as efficient as the not turned on mode. We got into the habit of leaving machines on because it took so long for them to boot in the first place. If it is taking a long time for the desktop machines to boot, then check the configuration. Still taking ages, even after removing all the unnecessary start up stuff? Then use the time constructively, like going for a coffee. Talking about coffee…
Use coffee Mugs, not disposable cups. How much time do disposable cups really save? How long does it take to wash a mug out people?
Recycle inkjet cartridges. Many businesses still use inkjet printers. They can be the cheap and easy option to put convenient printing in a manager’s office. Recharging the cartridge is so easy these days. Some companies, such as castleink, give cash back for empty cartridges and will even pay for the postage!
Opt for energy efficient light bulbs. Office lighting retrofits can be relatively inexpensive with quick ROI (five years or less). A lighting upgrade in one Pacific Northwest National Laboratory building resulted in annual electricity savings of $6,167 and 154,163 kilowatt-hours of energy.
Control office lighting with timers and motion sensors. Installing timers or motion sensors on CFLs and T8s set to stay on for 15 minutes or more provides a good balance of light life expectancy and energy savings. However, rooms that are occupied for shorter periods of time (bathrooms, storage rooms, and so on) should be fitted with light emitting diodes (LEDs) or incandescents with motions sensors or light timers.

These are all simple, straight forward steps. Getting people involved is generally not an issue, particularly as they feel they are doing their bit for the polar bears.

Social Networks in Business

Last week I heard on the radio that The Sunday Business Pos t Computers in Business magazine was doing a special ‘Social Networking in Business’ edition. Since I’m more of an online news hound, I can’t remember the last time I bought a physical newspaper, I put a reminder on my phone to pickup a copy of SBP on Sunday May 4th. Which I did. It’s a rarity these days, but Sunday was not too bad weather-wise, so I sat down in a local park to enjoy Computers in Business and the sunshine.

The three Social Networking sites focussed on where Twitter, Facebook and LinkedIn. Adrian Weckler‘s article about Twitter was a nice step by step guide to getting started, but lacked a business case for using Twitter in the first place. The other articles did at least provide some, but limited, business scenarios: Facebook for B2C advertising, LinkedIn for B2B advertising. This is perhaps an oversimplification of the articles, the online versions will not be available for a week or two. When they are I’ll link to them from this article and you can decide.

Business, and success in business, requires relationships, so Social Networking would appear to be the ideal tool. It needs to be carefully and thoughtfully applied though. When the only tool you have is a hammer, everything looks like a nail. So, with Social Networking one should be aware of how and when one is using it for lead generation, building a community of loyal fans, providing customer support, or just keeping in touch. Another important factor to consider is identity. I’m not talking about credentials, but rather who is being represented, the individual or the business? This is probably not too much of a concern for small businesses where the owner’s personality is blended with the brand. While it is taboo for a politician or celebrity to delegate their Tweeting to someone else, a large organisation is infact separate from the people who run it, so the Social Networking responsibilities often fall to the marketing department by default. However, the marketing department is not the only point of contact that customers, or potential customers, have with a business. A business using Social Networking sites should reflect that, ensuring that at least Sales and Customer Support have an involvement.

Staying on the topic of Twitter and business, Sarah Milstein recently spoke about Effective Twitter for Communication & Product Integration and touched on this matter of having individuals, recognised as real people, tasked with representing the business in social networks. Sarah often refers to two different companies with a similar approach to engage with their customers through Twitter. Wesabe, a personal finance site, and Comcast, a TV, phone and internet company, both use Twitter’s search feature to learn about what peopple are saying about them and respond accordingly. Sometimes this can be to address a complaint, or provide advice on a purchase.

If a business is made up of individuals, how does that business get meaningfully represented in a social network? One option, and I’m surprised it was not mentioned in the Computers in Business magazine is CoTweet. It is designed for businesses using Twitter to engage existing customers and attract new ones. CoTweet allows multiple people to communicate through corporate Twitter accounts and stay in sync while doing so.

Of course, microblogging is not just for external communication either. Increasingly, social networks have been appearing within the enterprise too. Yammer and Present.ly both provide private microblogging with features tailored for the workplace, like the ability to add attachments and to communicate in subgroups. Those who have found it useful report that email traffic is down, but information sharing and collaboration is up. Those who didn’t find it useful are still wondering what the fuss is about. It’s just another stream of information one has to struggle keep up with.

The use of social networks in the enterprise for internal or external communication does need to be carefully considered. In particular, one needs to be aware of what existing communication processes are being supported, and what new communication processes are required. This is where the adoption of social networks for business can struggle, not recognising the opportunity to use the technology to support new ways of doing business.

Priorities in agile software development

After discussions with friends, family and work colleagues over the past few months it became apparent that we all have a different idea on what priorities are and how do we identify priorities. Here are my thoughts on the matter.
Why prioritise?
It’s very dangerous to ask staff and customers what they want to see in the next release. The result is a mixed wish list of the most amazing things. By the time you’re ready to start development, you’ve got enough ideas for improvement to occupy 500 programmers for a few decades. A long list of features is a good place to start, but it needs to be prioritised.
Unfortunately, all you have is three, and we wanted to be shipping within 6 months, so there has to be some prioritisation. Time is an important resource, and we have a limited amount of it. With software, one does not have the luxury of a long development period to bring a product, or a new release of an existing product, to the market. Potential new customers will not be interested in a product that does not improve on a regular basis. Someone else may do it quicker. Your customers may migrate to a different solution that has the feature(s) they are looking for.

Capacity must be influencing our priorities. Because capacity is time based, our priorities are time based. Too many software development teams suffer from ‘inflation of time’; that is to say, they devalue future time by using it to solve present problems. The problems may not be the most important ones to solve today. Of course, the time spent on one thing means that some other activity remains undone. Each time we put off a portion of our work to do at a later date, becaue we haven’t time to do it today, we are devaluing future time in the sense that we now have less of it.

No one can juggle tasks indefinitely. Hard decisions have to be made about what matters. There can be a tendency for people to avoid the hard decisions and use capacity, or estimation of effort to set the priorities. For example, if the risk management feature takes more effort to implement we’ll go with the loan book profitability feature instead. While capacity is effective in determining what to do with activities of the same priority, it is not the only influencing factor in establishing a prioritised product backlog. There may be features that are must haves for the next release. They may be expensive to implement, but without them market share may not grow. This is where market research is really important. The product owner must be able to say: “To get the risk management feature we can sacrifice the loan book profitability feature because risk management addresses a need for a broader range of potential high value customers.” The product owner must also have the courage of their convictions and vision, based on their research and understanding of the market. Just because something is difficult does not mean it is not worth doing.

Prioritisation pitfalls

Sometimes certain features or activities can appear to be important and necessary in the next release. Here are some prioritisation pitfalls. If you find yourself condsidering this sort of features in your next release, spending some more time on research, verifying the importance.

Single customer requirements

It is generally cheaper to get new business from existing customers than it is to get new customers. Having customers can cause it’s own headaches, particularly if your sales person has sold the customer a product you don’t sell. This happens a lot more than it should, and opens the door to legal hassles that are just not worth the effort. Even when this doesn’t happen, there can often be enhancements suggested by your customers. Many of these will make sense, others may be bespoke features that no one else is interested in. Building features into your software based on single customer requirements implies that you are actually building consultant-ware, not shrinkwrap software. Shrinkwrap software is better than consultant-ware. That’s because shrinkwrap has no marginal costs for each additional customer, so you can essentially sell the same thing over and over again and make a lot more profit. Not only that, but you can lower the price, because you can spread your development costs out over a lot more customers, and lowering the price gets you more customers because more people will suddenly find your now-cheaper software worthwhile, and life is good and all is sweet. If you have customers that are requesting unique features not no other customer is requesting, then perhaps the real priority feature is a plug-in architecture, rather than the business feature.

Perceived inevitable requirements

Good software developers often think in the abstract so that the real implementations are more reusable in concrete scenarios. However, just because something is the next logical thing to do, does not mean it is the most important thing to do next. For example, a system may have a notification module with SMTP and SMS interfaces. A logical next step would be a XMPP interface for instant messaging. Such a feature may be interesting for the developer to work on, and may even give the marketing department something cool and trendy to draw attention to, but is it a deal clinching feature? Are more customers looking for this feature than some other feature, such as not notifying people who are on leave, but they’re deputies instead?

Prioritise interface that the user sees

A prioritised list, reflecting the capacity of the team, and what the business value of the new features are makes for a more sustainable development effort. There is one category of features that software developers may subconsciously discount. I’m referring to what the end user interacts with as a tool to for their job. The interface with your software may not be the GUI, but also a web service or a device. These deserve our attention because they increase the awareness of the value of what we can do with technology. Nobody sees a shared library or a driver, and no one cares about them, unless they’re broken. Yet that’s where software developers can tend to focus much of their time and resources. Doesn’t this contradict an earlier point about building a plug-in architecture? No. The motivation, in that case, to build something that the user does not see, is to provide a sustainable and cost effective solution so that the customer gets what they want (a business feature) without you having to provide it or maintain it.

A prioritised list, reflecting the capacity of the team, and what the business value of the new features are makes for a more sustainable (if no one pays for it, who pays the team) development effort down through the years.

Oracle SOA Suite Developer’s Guide

Service-Oriented Architecture (SOA) is not about technology, although technology is used to implement it. The principles of reliability and accommodating unexpected changes at a manageable cost can be applied equally in any programming language. However, as with most things in life, not just software development, it is easiest to use a model that is supported by tools and inter-operable (the ability of two or more systems or components to exchange information and to use the information that has been exchanged). A standards-based Service-Oriented Architecture (SOA), is such a model that enables IT infrastructure is continuously adapted to keep up with the pace of business change.

Matt Wright and Antony Reynolds have just published a book Oracle SOA Suite Developer’s Guide that provides a best practice guide to using the Oracle SOA Suite for building a real world applications. This book bridges the gap between SOA theory and the Oracle SOA Suite Manuals and is based on the experience of implementing SOA across a number of organisations in EMEA and APAC. It is a book of three parts. The first section of the book provides detailed coverage of all components of the SOA Suite, namely OSB, BPEL, Rule, BAM and OWSM. The second section addresses the common question: “What is the best way to combine / use all of these different components to implement a real-world SOA solution?”. Using a working example of an online auction site, it leads you through key SOA design considerations in implementing a robust solution that is designed for change. Though the examples in the book are based on Oracle SOA Suite 10.1.3.4 the book will still be extremely useful for anyone using 11g. The final section addresses non-functional considerations and covers the packaging, deployment, and testing of SOA applications; it then details how to use Web Service Manager to secure and administer SOA applications.

I’m sure this book will continue to be relevant in years to come to. Unlike other technical books, this one does more than just explain “how” to do A, B, and C, but goes to great lengths to explain the concepts. As a software developer it is vital to understand why we were doing what we were doing, so that we know which principles to apply in different situations.

Offshoring / Outsourcing with scrum

Clearly the use of scrum with distributed teams is something a lot of people are talking about right now. After last months article on scrum and offshoring, focusing mostly on communication challenges, I have noticed a number of blog postings on the subject. David Myers (a consultant at London based Charteris), in his article on Scrum and Outsourcing, goes into great detail about the challenges with distributed teams. For me, the key points are that basic agile practices of communication, meaningful documentation and continuous integration removes some of the hurdles. However, the manner that the standards / approaches applied have to suit the team.

I’ll leave the last word to David…

For me the most important consideration when employing Scrum with offshore resources is that it should not be employed without modifying and/or tuning some of the practices to be more suited to working with geographically split teams. This tweaking (or lack thereof) can have a fundamental effect on the end result.