There are many stakeholders in a new software product, be it commercial off the shelf or an in-house application. By stakeholders I refer to the people who will ultimately engage with and benefit from the product.
Outside-in thinking tells us to be explicit about whom the stakeholders for our projects, and knowing that, to gain a clear understanding of their goals. There are, for example, at least the business line managers, the end users, and your own architecture and standards teams. But some stakeholders seem invisible to all but the most cautious development teams.
Who are these discarded souls?
The IT operations team.
These folks have to install, run and support the applications we write.
How hard can that be, you wonder?
We - that is, the software developers - have a lot of control over that. Say we deliver multiple in-house applications. Do they run on the same platform pre-reqs, with the same underlying systems and even the same fix levels for those sub-systems? Maybe not. Sometimes you can't get uniformity because of valid capabilities concerns. Still, how hard is it for the operations team to manage this?
How about serviceability? When an end user complains, is it an ops problem or an application bug? How difficult is it to figure out? Can you support a full application life-cycle, with seamless handoffs between operations and development, sharing trace logs, and the like? Meanwhile, the first order of accountability is on the ops team, putting pressure on them to keep to the service level agreement and explain away any deviations.
How about metering? Maybe development wants to counter performance complaints about an application by saying, "add more CPU!" Can the ops guys readily determine the loading on the app?
Oddly enough, these invisible stakeholders can actually make or break the success of our software. When I design software I try to consider these stakeholders as silent partners of the business manager sponsoring the need for the product or application.
Teams tend be more successful when they remember the operations team is a full-fledged stakeholder for their software. The ability of the ops team to consume software ends up being reflected to their end users and clients in performance and stability.
What's the path to improvement here? Outside-in development techniques, such as clear stakeholder identification and consumability analysis can be of particular help to operations teams.
Carl Kessler is vice president of worldwide development with the IBM Software Group, having led large software development organizations at IBM for more than a decade, primarily in the enterprise content management, systems management, security, and networking arenas. He is author, along with John Sweitzer, of the new book just published by IBM Press, titled: Outside-in Software Development: A Practical Approach to Building Successful Stakeholder-based Products.