09.22.03
Posted in IT Governance at 12:29 am by Tony Baer
Ironically, while IT organizations are often in the thick of enterprise reengineering projects, when it comes to their own operations, study after study reveals IT groups don’t practice what they preach. Typically, IT organizations have about a 20 – 30% chance of delivering projects on time, on budget, and with the promised functionality. Is that any way to run a business?
Increasingly, CxOs are just saying no. Expanded outsourcing, reduced IT budgets, and debates over IT’s relevance are the symptoms that top management has had enough.
Some observers claim that the problem is — you guessed it — a lack of software.
IT performance involves tracking a wide variety of professional disciplines and activities, where there is plenty of niche software. Systems management frameworks, for instance, track the health of the infrastructure, while project management tools track the health of individual projects. The same is true for testing tools and software quality, and certification programs (e.g., the Capability Maturity Model) and software engineering. And if you really want to pit IT against outsourcers, there are fancy timesheets for enabling IT groups to bill time and materials just like Accenture. While each tool answers one or two questions, none of them paint the big picture.
Mercury Interactive is the most prominent player to tackle the issue. Having dominated the software testing space, Mercury has reinvested some of its cash horde into key acquisitions to assemble what it calls an ERP solution for IT operations. Recently, it added a governance module to its suite of software defect, quality, and performance testing tools, now called Optimization Centers. In the long run, the value of such suites will be correlating data — such as delays from a project management system or defect incidence from a testing system to risk management activities in governance modules — to advise you when to pull the plug. Mercury and smaller rivals like Euclid are still figuring this one out.
Ironically, while IT has worked on projects to eliminate organizational stovepipes elsewhere around the enterprise, it has not done so in its own backyard. Within the technology organization are application developers, software testers, database administrators, systems operators, and network managers. Meanwhile, the telecom group remains a separate fiefdom.
Not surprisingly, problems, such as poorly performing software, are often thrown back and forth between development, testing, and systems admins. Meanwhile most IT organizations only pay lip service to real process improvement ideas — such as concurrent software design and testing — that could improve performance and quality, while reducing project delays.
Consequently, before IT organizations can take advantage of emerging IT governance solutions, they will have to administer a bit of their own reengineering medicine on themselves.
Permalink
09.10.03
Posted in Application Development, Enterprise Integration, SOA & Web Services at 12:28 am by Tony Baer
Nobody needs reminding that systems integration has long been a black hole for IT projects. Software history has been larded with ill-fated attempts to standardize the way programs integrate, from proprietary technologies like IBM’s Systems Application Architecture (SAA) to SQL relational databases and Rube Goldberg-like CORBA component architectures. Yet, integration continues to be the costliest part of any software project.
More recently, middleware has become the most popular integration approach, with most tools using proprietary technology-based hubs to direct interactions between applications, messaging systems, and data sources.
All of these approaches failed because of their rigidity. That’s not surprising. Conventional software programs were monolithic — they combined lots of functions in lockstep, running every transaction against preset targets. So if you changed the data or business logic of a given transaction, those changes had to cascade back to every process, message, and data source they touched. When enterprise application integration (EAI) middleware emerged, it worked the same way.
Now a reinvention of an old idea, the Services-Oriented Architecture (SOA), threatens to replace hard-wired connections with a service request model that could prove far more pliable. Unlike conventional systems, SOAs simply specify information or service requests, they don’t specify which system must respond. In the long run, that has huge implications for making integration easier.
XML Web Services are a new set of standards for applying SOAs. So far, the industry has coalesced around the basic building blocks: how to build service requests (SOAP), how to declare services (WSDL), how to list them in a directory (UDDI), and how to specify security and digital signatures. Not surprisingly, vendors haven’t agreed on the higher-level stuff verging on business logic, like describing or choreographing business process workflows.
Every tech fad needs some cold water, so here’s it. SOAs might simplify integration, but they won’t make it simple or commodity. As we learned with ERP, customization remains necessary because every company runs itself differently. SOAs won’t replace monolithic software, but complement it, providing ways of standardizing how existing systems talk to each other. And don’t confuse SOA with web services. You can implement SOAs without XML web services, and vice versa.
We were reminded of the latter point after last weeks’ HP acquisition of Talking Blocks, a startup offering tools to manage web services. HP’s goal was to round out its OpenView systems management framework with capabilities to manage SOAs in general, not just web services.
In the long run, XML web services will become the primary means for implementing SOAs. But that’s at least 3 – 5 years off. In the meantime, we still have lots to learn about SOAs. Many first steps will be false steps, like using SOAP messages to connect the same old monolithic software in the same old monolithic ways. These days, you can’t ask for quicker progress, and you wouldn’t want to.
Permalink