TECHNOLOGY VIEWPOINTS
Go-to-market approaches: How suites and constrained releases affect architecture
This issue of CGI’s Technology Viewpoints examines how the go-to-market approaches of technology product companies significantly affect solution architectures. What can be purchased and at what price constrains architecture component decisions. From an this perspective, the optimal choice is to select components that are standards based, available from two or more suppliers, and represent best of breed.
- Standards-based components are expected to ensure interoperability, reduce adoption costs and prevent vendor lock in.
- Free market forces—where two or more suppliers with similar offerings compete openly—are expected to ensure reasonable pricing, where adequate profit is available to support vendor and product longevity.
- Architectures based on best of breed have the potential to deliver the highest IT value, providing that price performance is balanced.
There are two go-to-market approaches that can stand in the way of achieving best of breed. One is the bundling of software components into suites, which focuses on single vendor integration and high functionality at a correspondingly high cost. The second is the constrained release of products to specific hardware, operating systems, networks and devices. These are not engineering decisions; they are go-to-market decisions made to constrain customer options and maximize vendor ROI.
This issue discusses the result of the consolidation trend in the industry of products into suites and smaller companies into larger companies. This activity has culminated is less options for customers and greater lock-in, meaning you must rely on single suppliers for software and/or hardware. Standards help reduce this lock-in as does an architectural framework within which to make decisions. Suites add value in that pre-integration is performed by the vendor. The challenge for IT organizations, however, is to control their own IT roadmap to optimize their ROI rather than that of their suppliers'.
This issue takes a look at the topic from four key viewpoints:
End-to-end lock-in is the norm
The telecommunications world is traditionally thought of as being based on standards and interoperability. From a mobility perspective, there are two incompatible networks, CDMA and GSM, and two incompatible enterprise connectivity overlays, Blackberry and Microsoft. The lock-in is end-to-end, meaning the reliance on that vendor extends throughout the operating environment from end user to the data center. From a technology perspective, there are no show-stoppers that prevent interoperability within the architecture. In this case, constrained release is in play.
To provide some context, there are two predominant mobile communications options for the enterprise today: 1) the tried-and-true Blackberry solution with its handsets and enhanced carrier network and the Blackberry, Microsoft Exchange or IBM Notes servers, and 2) the Microsoft platform with Windows Mobile on the device side, Windows Server and Microsoft Exchange on the server side, and carrier networks in the middle. Don't look to use a Blackberry outside of the Blackberry world and don't expect to use Windows Mobile on your enterprise's Blackberry infrastructure.
Despite various announcements that might give expectations to the contrary, today there are two divergent paths: a Blackberry path and a Microsoft path, and nary the two to meet. Why is this significant to the enterprise? Mobile applications of tomorrow will coexist with the handheld devices and messaging infrastructure that support mobile e-mail today.
A desktop operating system is a place to run applications
All can agree that the Microsoft Windows Desktop environment is the ideal place to run applications developed for the Windows Operating System. However, there are a few leading alternatives:
Alternative 1. Apple provides a proven and industry-accepted alternative that has a relatively small market share and is positioned to stay that way. The Apple experience is powered by Intel processors and standard PC components, yet it is only available on Apple computers. The de facto industry standard Microsoft Office Suite is supported natively. An accepted, alternative desktop operating system exists yet there are no indications from Apple that they are in this business. Constrained release—and one could argue that the suite approach—is in play. Apple doesn't go to market with an operating system; they go to market with a software, hardware and application suite approach.
Alternative 2. One way to look at desktop computing is that the browser is the desktop. We look back in time to desktop devices, namely the dumb terminal, the X terminal and the standalone PC. The dumb terminal provided a basic user interface for a remote computer. The X terminal still provides a rich user interface for a remote or local computer. And the standalone PC brought the computer to the user. To contrast a browser and an X terminal, one can view the X terminal as a user interface for a single computer and a web browser as a user interface for a network of distributed applications. One can look to Google (gmail) and others for feature-rich examples of what can be accomplished with a browser at the application level. The browser is the equalizer of operating systems. It matters little if the operating system is from Apple, Dell, HP, IBM, Linspire, Microsoft, Motorola, Nokia, Novell, Palmsource, Red Hat, Siemens AG, Sun, Wyse or Xandros. All it needs is an active network connection with reasonable service levels. It is a different style of computing than a standalone PC, but if the primary purpose of the PC is to host a browser, it winds up exactly the same.
A lot of discussion has been had over the last few years regarding Desktop Linux. The biggest obstacle has been the constrained release of Microsoft Office, which prevents the cost-effective choice of running it on Linux. The discussion needs to turn to the applications and not the operating system.
Beware of the servers
The advent of Office 2007 brings forth greater emphasis on the server’s role in office computing. The cornerstone of Microsoft Office from the server side has been Exchange. The active use of server processing will increase in the new Microsoft Office version as will the dependency on server-side processing for the end user and Microsoft Windows servers for the IT department. The Office suite is in effect being expanded from a desktop suite to an enterprise-level suite.
This will bring higher functionality and higher costs. ROI on this expanded footprint is possible if the new technology is exploited appropriately. The alternative is an increase in IT spend with reduced ROI. In a lot of cases, enterprise agreements are such that upgrading to the new version can not be ignored. This go-to-market approach has definite implications for IT departments and end users.
Office 2007 continues the rich client model and adds a rich server model as there is a close coupling between the client and the server. The browser-based model leverages computing and display capabilities of the client but has a high dependency on servers. Where the Office 2007 model has a close coupling of client to server, the browser model has a loose coupling of client to server. Loose or close coupling aside, both models introduce an increased dependency of business applications on networks.
How much is that SOI in the window?
Service oriented infrastructure (SOI), which supports a service oriented architecture (SOA), is the latest buzz phrase. Large scale and enterprise-wide in scope, an SOI addresses the SOA aspects of governance, security and identity management, business process modeling, registry services, service identification, enterprise service bus, testing, operations, performance management and orchestration services, to name a few. As with most adoptions of new technology, phased implementation is possible. A full SOI suite implementation is not necessary, nor is it necessarily the most pragmatic approach. A full SOI implementation brings with it a learning curve and additional IT infrastructure. All this activity takes time and money. Assessing the ROI and executing a well thought out plan is key. The challenge is to tailor the various vendor offerings to keep the new SOI expenditures in line with the value provided.
The key to successful SOA implementations is the optimal application of both SOA and SOI in context with strategic and tactical needs. This may require unbundling the SOI suite to right size deployments to your ROI and timelines.
Suites and their focus
There are three predominant suites targeted at Microsoft-, IBM- and open source-oriented application development. It would be no surprise to find that the Visual Studio Suite from Microsoft has a predominant focus on Microsoft-based development. Similarly, the rational suite from IBM has a slant toward IBM middleware and Java. The open source Eclipse environment has a focus on supporting technologies relevant to open source development and application infrastructure.
A number of other suites exist that provide direct support for other platforms/products. Oracle has their own suite of tools optimized for use with Oracle products. SAP has their suite targeted toward SAP development. There are tools—and suites of tools—to support PHP development specifically.
The reality for the enterprise is co-existence of these suites. There needs to be efficiency across the enterprise. Common toolsets reduce training and increase efficiency; however, tools targeted for a particular type of development also deliver efficiency. Interoperability between these suites is not high. Many enterprises find it necessary to use multiple suites within their enterprise. This constrained release of functionality, driven by a single vendor focus, drives down customer ROI.
Alignment of overlapping functionality and judicious use of vendor tools with their suites is necessary to optimize the enterprise's application infrastructure.
|
