November 25th, 2009
Posted by Joe McKendrick @ 7:52 am
Categories: General
Tags: Commercial, Baggage, Desktops, Enterprise Software, Hardware, Software, Joe McKendrick
Okay, we all know cloud computing has plenty of issues and risks, but as far as perceptions go, it definitely has the “cool” factor these days. So just imagine if the same advertising agency that created the “I’m a Mac-I’m a PC” commercials for Apple were charged with selling cloud computing. 
I ran the script over at Insurance Networking News last week, and thought I’d share it here as well.
You probably know the storyline by now for the Apple commercials — the uptight, fuddy-duddy PC guy trying to stop people from moving from Windows to Mac. In a cloud commercial, the cool, laid-back Mac dude would likely be the “Cloud” guy in this case, and the uptight PC guy—shown to be bedeviled by bugs and problems—would be the equivalent of the “Enterprise Software” guy.
Such a commercial would probably go something like this:
Cloud dude: Hello, I’m a Cloud.
Enterprise suit: And hello, I’m Enterprise Software. (Struggling with three huge suitcases)
Cloud dude: Enterprise, what do you have in those bags? They look heavy.
Enterprise suit: These? Oh this is all the baggage I bring along with me to customer sites. You know, up-front licensing costs, upgrades, service packs, installation kits, extra hardware, extra disks; you know, all the stuff that I need to set up at a customer site.
Cloud dude: You need a hand with that? You know, I don’t really need any of that when I go to customers—I travel pretty light. (Extends both free hands to offer assistance)
Enterprise suit: No, no, I’ll be fine. I’ll just … (Starts walking, falls over, flat on the floor, baggage landing on top of him, rumpling his suit.) Besides, my customers always know to keep a spare room open for all of my baggage when I arrive.
Cloud dude: (Shrugs and smiles.)
November 23rd, 2009
Posted by Joe McKendrick @ 2:49 pm
Categories: General
Tags: Interoperability, SOA, Enterprise Service Bus, Service-Oriented Architecture (SOA), Middleware, Enterprise Software, Software, Web Services, Joe McKendrick
Of the 17 original authors of the SOA Manifesto (including yours truly), Anne Thomas Manes was one of the most — if not the most — powerful and influential voice shaping the formation of the final document.
Anne just posted her analysis of the Manifesto document, which is definitely worth a read if you seek to understand the thinking behind the wording of the core values and guiding principles.
Anne made many clarifying points, and I’ll highlight a couple that bear repeating:
On “Intrinsic interoperability over custom integration”: “To some degree, I’m surprised that we were able to get the ESB vendors to agree to this value statement. If you build services that support intrinsic interoperability, you really don’t need an ESB. Of course you might use an ESB as a service container (not just as a mediator), in which case you can use the ESB to expose an intrinsically interoperable service. I’ll just point out, though, that RESTful services are more intrinsically interoperable than other types of services.”
On “Shared services over specific-purpose implementations”: “I find this value prioritization is … missing in many organizations. Unfortunately, the impediment to using shared services is a cultural issue that’s very hard to overcome. Many organizations suffer from chronic ‘I’m special’ and ‘not invented here’ syndromes, both of which often represent trust issues.”
Anne also points to the fact that we use the term “shared” rather that “reusable” in the above value statement. She observes that “we had pretty strong consensus among the authors to avoid the term ‘reusability.’ We prefer ‘use’ rather than ‘reuse.’ … Reusability is a tricky subject. A few years ago, I thought that service reuse was fundamental to the SOA value proposition… But I’ve backed away a bit from that focus on reuse. Designing for reuse is expensive, and many services will never be reused.”
The potential for sharing of services, however, should be considered at the initiation of a project, and these points are embedded with the Manifesto’s value statements elsewhere as well. As Anne puts it: “Designers should always consider whether the services they are building could have value to the organization beyond the scope of the individual project. If so, they should design the service for reuse by concentrating on getting the granularity right and by adopting corporate standard data models that enable intrinsic interoperability.”
November 23rd, 2009
Posted by Joe McKendrick @ 7:28 am
Categories: Management
Tags: Workplace, Cyber Monday, Workplace Computer, Recruitment & Selection, Human Resources, Workforce Management, Joe McKendrick
Cyber Monday is just around the corner — on November 30th this year, and some observers are expressing concern about the potential hit on productivity businesses will suffer. Others worry about the overloading of and risk to corporate networks. Many employees will be using their companies’ bandwidth to shop ’till they drop on Cyber Monday and beyond. Should businesses be concerned about all this retail activity taking place on their dime?
Some worry that Cyber Monday puts corporate networks at risk and kills productivity. Are they just being Scrooges, or do they have a point?
According to a survey conducted by ISACA, the IT governance association, 63% of people of all ages say they shop online during the holiday season from their workplace computers. There appears to be a real cost to all this holiday spirit, however, as IT professionals in the survey calculate that their company loses an average of $3,000 or more in productivity per employee from online holiday shopping at work.
More than half, 55%, also reported that their company permits workers to shop online but has no strategy for educating them about the risks.
SpectorSoft president C. Douglas Fowler puts it this way: “Many companies are not prepared for the sudden drain on resources caused by employee online holiday shopping during work hour. When businesses anticipate or experience the loss of revenue and productivity around Cyber Monday and the Holidays, they begin looking for ways to find out exactly what their employees are doing.”
Productivity is one concern. CareerBuilder says employers lost $580 million in productivity on Cyber Monday in 2008. They estimate that 43% of those planning to shop from work on Cyber Monday will spend at least one hour doing so, and 23% said they shop two hours or more from their workplace computer. Another concern is the vulnerabilities that will be introduced to workplace computers — there is an increased risk of spam, viruses and phishing attacks in the workplace.
Should employers crack down on these practices? Is it even worth the effort?
On one hand, it may be the equivalent of standing in the middle of 7th Avenue and yelling for the traffic to stop.
There’s another way to look at the issue as well. Are the employees that are taking a couple of hours to online shop still getting their work done? In an era of online business and networks, enforcing 9-to-5 productivity may be, well, counterproductive. The lines between work and personal life are blurring.
First of all, the ability to use workplace computers to do things like holiday shop is a relatively painless way to maintain employee morale. Plus, the way work gets done in today’s information economy is via teamwork and “burst productivity,” in which work may get accomplished outside the boundaries of corporate schedules and firewalls. Many professionals are ready and willing to work on their own time — why wouldn’t employers allow for the opposite as well?
Yes, companies need to be vigilant about viruses and malware, and help employees practice safe online shopping. But trying to crack down represents the rigid thinking of older times when there was a huge wall between business and personal lives.
November 21st, 2009
Posted by Joe McKendrick @ 8:11 am
Categories: Links
Tags: Buzzword, Blogging, Internet, Joe McKendrick
There’s no shortage of buzzwords buzzing around the blogosphere, analystsphere, consultantsphere, conferencesphere, and everywhere else-sphere. (And yes, they spill over into this blogsite as well…) Geek & Poke’s Oliver Widder takes a poke at the buzzword bubble that often gets in the way of tangible and solid evidence that things work.
From Geek & Poke http://geekandpoke.typepad.com/geekandpoke/
By the way, the buzzphrase ‘Business-IT alignment’ gets my vote for the most overused, yet most useless, phrase of all.
November 20th, 2009
Posted by Joe McKendrick @ 8:16 am
Categories: Business ROI, Case Studies, Data managemetnt, Management, SOA Events, Vendor Watch, Web Services, cloud computing
Tags: Cloud, Cloud Computing, Virtualization, Hardware, Joe McKendrick
The purpose of information technology is “to provide compute and storage. That’s it. full stop. That compute and storage can be provided by mainframes, private data centers, distributed networks, or by the cloud.”
- Allan Leinwand, venture capitalist
At this week’s Interop conference in New York, I heard a great panel discussion, moderated by AT&T’s Joe Weinman, on the economics of cloud computing. Weinman was joined by Adam Selipsky of Amazon Web Services, Allan Leinwand of Panorama Capital (which invests in cloud vendors), Andy Rhodes of Dell, Harris Tilevitz of Skadden Arps, one of the largest law firms in the world, and William Forrest of McKinsey & Co., author of the last spring’s watershed report on “Clearing the Air on Cloud Computing.”
A public cloud provider, private cloud operator, consultant, network provider, and venture capitalist debate cloud’s business value
McKinsey’s Forrest, for one, stated that while his research “found significant amounts of workloads today could be moved to public cloud providers,” it still “wouldn’t make economic sense to move large chunks of data centers to the cloud.”
Nevertheless, he predicts, “there will be a continued move to the cloud, as there are increasingly attractive economics over people building their own data centers.” He says that these economics keep getting better because “the public cloud guys have built a better box, they buy in volume, and operate more efficiently than most enterprises.”
“The idea that you buy an individual server, that is going away. You either buy racks of servers or go to the cloud.”
Amazon’s Selipsky, needless to say, was bullish on the cloud computing paradigm. He noted that in a government CIO rountable last week, Vicek Kundra, the US CIO, “certified that 45% of all government IT could run on public clouds.”
Selipsky went on to say that cloud computing is suitable for both large and small enterprises. “For start-ups, its a total no-brainer. We also have a lot of big enterprises using our services.” He foresees many enterprises moving to a hybrid cloud environment in the coming years. And, he noted that cloud providers also bring another advantage beyond cost savings: “The biggest benefit of the cloud is that is it enables focus. You can take the intellectual capital of your staff and focus on your business — not IT.”
VC Leinwand, however, says he still sees a “huge gap” between cloud services offered and the ability to effectively manage them in an enterprise environment. “Cloud storage costs one-tenth of onsite data storage,” he points out. But what about configuration, integration, data deduplication, and monitoring? There’s a gap between what the enterprise is used to doing behind the firewall and what cloud providers can do.” He added that he is seeking to fund companies that can help close that gap.
AT&T’s Weinman, for his part, raised doubts about the sustainability of cloud computing economics, which may break down as enterprise management requirements come into play. “I’m not sure there are any unit-cost advantages that are sustainable among large enterprises,” he said. A more likely scenario that will be seen is hybrid adoption of cloud computing in some areas, and private capabilities for others where it makes business sense.
Another option is private clouds, and Skadden’s Tilevitz reports great success at his global law firm of 2,000 partners. Originally, the initiative started after September 11, 2001, as a way to ensure business continuity by operating three regional data centers. Now, built on a Citrix environment, the virtualized environment has evolved into an internal cloud of sorts, from which the firm’s various office access online services. For example, he related, a partner may need to load five million pages of documentation into an online format overnight. “We have more than a petabyte of image data that we keep for seemingly forever that we use for litigation,” he said.
Economies of scale have also kicked in as well. “Our expenses for this private cloud have dropped over time,” Tilevitz said. “I see it as almost a reversion back to the mainframe world. Everyone is now using applications and data remotely.” Tilevitz also said his firm is looking at becoming a “public” cloud provider of sorts as well, selling excess disk capacity online.
November 18th, 2009
Posted by Joe McKendrick @ 1:34 pm
Categories: Case Studies, Data managemetnt, Enterprise Architecture, Management, Standards Watch, Web Services, business process management
Tags: SOA, Simple Object Access Protocol, United States Coast Guard, Service-Oriented Architecture (SOA), Web Services, Middleware, Enterprise Software, Software, Joe McKendrick
This is the third of three installments of my discussion with Jim Jennis, chief technology officer for the US Coast Guard Operations Systems Center, and Steve Munson, SOA branch chief for the US Coast Guard, about the department’s growing roster of service-orientation initiatives. In the first post, Munson and Jennis described the business case for SOA within the Coast Guard. In the second post, they discussed how they built organizational support.
Coast Guard opts for ‘lightweight’ services; now tackling governance and security issues
The US Coast Guard prefers more lightweight services for its maritime and inventory tracking systems. “We are very REST oriented,” Munson explains. “We like the REST model very much. So where applicable, we have leveraged it in a significant way to develop our service oriented architecture. Internally, Munson points out, the prevailing standard is POX, or Plain Old XML for message exchange. “We do not subscribe to the extra wrappers and envelopes and overhead that’s required to serve out SOAP-based services.”
“What we have found within the Coast Guard is that the Web services model, particularly the traditional RPC-style Web services, are not suitable for implementation in the Coast Guard’s architecture,” he explains. “Our architecture is fundamentally message based. Where we do implement Web services interfaces, they’re all document-driven Web services for external users, where those kinds of interfaces are required.”
Munson and Jennis are also seeing some reusability in its SOA-aware services, particularly for lower-level services. However, Munson cautions, “we certainly don’t want to oversell that yet.”
That’s because the SOA team is still wrestling with the technical aspects of service governance. “The issue around SOA governance is still a challenge for us as it is with any organization,” he explains. “We have not implemented, for example, any formal service registry or automated service discovery. Were continuing to look at how we want to do that.”
The issue with registry and repository solutions on the market, he says, is that they are oriented toward the traditional SOAP-based Web services. “Most of them are still tailored to the Web services approach,” he says. “Many of them don’t have good answers for non-WS-* type of registration.”
Data security is another challenge for the Coast Guard’s SOA team, and this is holding back the ability to offer services to port partners and other outside parties. “One of the challenges in an enterprise service bus, and an SOA architecture in and of itself doesn’t solve this, are all the security challenges surrounding data services, particularly once you get outside of your organization,” Munson says. Internally, within the Coast Guard organization, the security around services is pretty straightforward. But starting with sharing with external partners at any level, security rapidly becomes a challenge for us. Like other folks, were still looking at how to crack that nut, and we still don’t have a silver bullet for that yet.”
The Coast Guard soon intends to make some services available to other federal agencies and its port partners. For example, the Coast Guard is participating in an inter-agency program called Watchkeeper, in which data is provided as part of a homeland security system. “We have probably a dozen or more services that are in testing that will be deployed as part of that system,” Munson says.
Additional services being piloted — and still in development — will feed data to and from WatchKeeper to other Coast Guard systems, such as MISLE, MAGNet, MASI and others, Munson adds. Additional services leveraging the Coast Guard’s ESB and SOA include systems for the National Oceanic and Atmospheric Administration surrounding Right Whale speed enforcement zones, as well as a system for monitoring and tracking Self-Locating Data Marker Buoys (SLDMB) for Search and Rescue.
The Coast Guard is making substantial progress with its SOA effort, and Jennis and Munson credit this to the close coordination between their teams and the Coast Guard management. “If you define what SOA means for your organization, and go forward with that, you’ll get SOA right,” Jennis advises. “In our case, we’re very much tied to the Coast Guard’s mission, and the doctrine of the Coast Guard. But if you go with a lot of the buzzwords, and you don’t have a clearly defined meaning for what your SOA will look like, you’ll get in great trouble in a hurry.”
November 17th, 2009
Posted by Joe McKendrick @ 10:39 am
Categories: Case Studies, Data managemetnt, Enterprise Architecture, Management, business process management
Tags: SOA, United States Coast Guard, Service-Oriented Architecture (SOA), Web Services, Middleware, Enterprise Software, Software, Joe McKendrick
This is the second of three installments of my discussion with Jim Jennis, chief technology officer for the US Coast Guard Operations Systems Center, and Steve Munson, SOA branch chief for the US Coast Guard, about the department’s growing roster of service-orientation initiatives. In the first post, Munson and Jennis described the business case for SOA within the Coast Guard.
The Coast Guard dipped its toes cautiously into the SOA waters
The Coast Guard’s SOA initiatives had top-level support early on from the upper echelons of management. “We’d been challenged by our new commandant, Admiral [Thad] Allen, to become a department leader in SOA, and the department was taking a hard look at that time on where they wanted to go with their SOA roadmap,” Munson explains. “So it was just an opportune moment for us to dive into this, and see if there was any technologies that made sense, and that we could leverage. So we’ve taken a very deliberate, very measured approach to this, and started with a lot of small pilot projects, to validate, not only the technologies, but the architectural concepts that we’re trying to support with them.”
Even with strong organizational support, the Coast Guard’s SOA team approached the effort from the ground up, starting with smaller pilot projects. The approach was “build a little, test a little,” Jennis says. “We took a very measured and deliberate approach to SOA – no ‘big-bang’ projects. Everything was carefully architected and focused at the business architecture, the mission support of the Coast Guard first and foremost. And the technology implementations were validated and tested against that architecture in business-focused pilots. That is key to our success so far – being able to take things slow, validate the architecture, focus on the business, and make sure got it right before we started rolling this stuff out in production.”
Since the Coast Guard’s IT budget is small and highly fragmented across functional areas, the team did not have a big budget in which to engage its SOA effort, Jennis and Munson say. But the effort has delivered results well beyond the relatively lean expenditures made for the program. For example, the Coast Guard now can quickly pull up real-time data on ships that are entering US waters.
“We can also support maritime domain awareness by fusing data from multiple different data sources,” Munson adds. “We have, for example, requirements from homeland security for ship-arrival notifications 96 hours before a vessel enters a US port. That data can be fused with a long-range tracking system that identifies whether vessels are really going where they say they are going. Its tremendous value to promoting homeland security.”
The Coast Guard has also employed SOA to better track and manage its spare parts inventory – potentially saving the service tens of millions of dollars. “We developed what we call an ‘authoritative parts service’ that was able to identify and accurately catalog the value of the Coast Guard’s spare parts inventory,” Munson says. “We identified in that category more than $60 million worth of incorrect Coast Guard inventory evaluation. Measuring that against the federal cost of funds index – which is like interest on your money – it saved the Coast Guard $60 million, times the value of the federal cost of funds.”
Next post: By necessity, a RESTful approach — and unresolved issues.
November 16th, 2009
Posted by Joe McKendrick @ 2:06 pm
Categories: Business ROI, Case Studies, Data managemetnt, Enterprise Architecture, Management, Vendor Watch, Web Services
Tags: Homeland Security, SOA, United States Coast Guard, Service-Oriented Architecture (SOA), Web Services, Middleware, Enterprise Software, Software, Joe McKendrick
Did you know the movement of any ship headed toward US waters is tracked by an SOA-aware service running on the US Coast Guard’s systems? And that SOA services are being employed to provide data to an international registry of maritime activity? And there is also an SOA service keeping track of the all the spare parts, equipment, and other assets the Coast Guard maintains? 
The Coast Guard already has close to 25 services that are either already or about to go into production as part of its growing SOA initiative – and more are planned. I recently had the opportunity to speak with Jim Jennis, chief technology officer for the US Coast Guard Operations Systems Center, and Steve Munson, SOA branch chief for the US Coast Guard, about the department’s growing roster of service-orientation initiatives.
The Coast Guard – part of the US Department of Homeland Security – started looking at SOA in early 2007, as a way to address growing requirements to be able to share information not only across its own various units, but with federal, local and international agencies concerned with keeping an eye on vessels entering and leaving US shores. “We had the same conundrum of silos of excellence that many IT organizations have – IT systems tailored in stovepipes within lines of business,” says Munson.
Prior to its SOA implementation, the Coast Guard relied on slower and more manual methods of data sharing with its port partners. “It would either be some form of composed file that would be potentially handed over, or many times, a hard-copy printout or phone call,” Munson relates. In addition, sharing data with its fast-moving cutter fleet was also a challenge. “The cutters get underway and go where they’re needed, so we have fairly low-bandwidth connectivity to these kinds of assets at best,” Munson says. “So were also looking at not only data sharing, but also if there’s a better way with emerging technology to help address some of the problems of being able to use our systems with deployed assets.”
To address these requirements, the Coast Guard implemented an enterprise service bus-centered SOA that enabled asynchronous messaging from Fiorano Software Technologies. The solution was employed in the Coast Guard’s Long Range Identification and Tracking (LRIT) system, which at any given time, is tracking up to 6,000 vessels moving toward or in US waters as well as vessels anywhere else in the world. LRIT tracks signals emitted from vessels every six hours. “That information is running entirely on the Coast Guard’s SOA framework in production,” says Munson. As a result, the Coast Guard SOA requires extremely high-volume services, “processing thousands of messages per second.”
A second system, the Nationwide Automated Identification System (NAIS), relies on a second transponder on ships exceeding 300,000 gross tons, broadcasting navigational information for ships of 300 gross tons or more at three-second intervals. These broadcasts from US territorial waters result in about 2,000 messages per second received in the NAIS system. The Coast Guard is currently protoyping various data services around this system for maritime domain awareness, Munson says.
This is the first of a three-part series. Next post: How the Coast Guard built organizational support for SOA.
November 14th, 2009
Posted by Joe McKendrick @ 9:47 am
Categories: Business ROI, General
Tags: Information Technology, Geek & Poke, Strategy, Management, Joe McKendrick
Geek & Poke’s Oliver Widder picked up on my latest post on the lack of measurable results for IT, and posits as to where the greatest IT project risk may be found:
November 13th, 2009
Posted by Joe McKendrick @ 10:14 am
Categories: Business ROI, Data managemetnt, Enterprise Architecture, Management, Vendor Watch, Web Services
Tags: Data Service, Data Quality, SOA, Ash Parikh, Service-Oriented Architecture (SOA), Web Services, Middleware, Enterprise Software, Software, Joe McKendrick
A couple of months ago, as reported here, Neal Fishman released a book that warned of SOA-based infrastructures helping to spread “epidemics” of viral data across enterprises — since data can be pulled from multiple, formerly siloed sources and quickly distributed across service-oriented systems and applications.
How much data pulled from multiple sources is bad data?
Informatica’s Ash Parikh, a long-time advocate of the data services approach to SOA, has also been warning of this scenario. I have gotten to know Ash through our participation on the Informatica Perspectives site, and recently had a chance to talk to him and Informatica’s Chris Boorman prior to the launch of Informatica 9, which embraces the SOA data services concept.
Ash proposes that organizations adopt a data services layer that provides “a model and standards-based reusable data abstraction layer that can make holistic, accurate and timely information available to an enterprise integration infrastructure, without all the typical complexity and maintenance costs.” He defines a data service as “a modular, reusable, business-relevant service that enables the access, integration, and delivery of complex enterprise data throughout the enterprise and across corporate firewalls in batch, near real-time and real-time modes, including federation.”
As companies move into the next level of SOA maturity, in which services start reaching across enterprise boundaries, many have been struggling to improve SOA’s ability to deliver business value. One factor is companies can’t trust the data that is being pulled in from all the stovepipes into enterprise services. SOA, as Chris puts it, “has lacked the data abstraction layer that enables organizations to basically define the data objects and the rules associated with data objects, that can then be permeated through — whether it be Web services or SQL or batch or anything else — to the applications that are using that data.”
Ash, who has been warning the industry about the quality of data — or lack thereof — surging through SOA-based infrastructures for some time now, says SOA data services open up many new avenues for connecting SOA with enterprise data management. “It’s much more than just data access,” he points out. “It’s making sure the data that is delivered is of the greatest quality.”
SOA data services also helps create a more collaborative environment between IT, data managers, and business data owners. In the real world, Ash says, “when people talk about data, they never talk about ‘data source X’ or ‘data source Y’ that’s sitting in a corner somewhere,” he says. “They report the data as a business representation of data — my customer data, my product data, things like that” This brings things in line with the perspective required of SOA architects, who need to better assure more timely and accurate and consistent views of their data and the product data.
Given this backdrop, I saw that Mike Kavis also has been doing work in this area, and just posted a business case for data services at his site. He describes the issues that can be rectified via an abstracted data layer: real time failover among multiple virtual data centers; managing multi-channel partners with multiple data structures; regulations and laws affecting data management and movement; and data security against direct access to databases.
Maintaining a loosely coupled data services layer takes away the complexities and inconsistencies of attempting to manage multiple data sources. “By abstracting the data layer and creating configurable services as access points to the data, teams can quickly implement solutions in a controlled and standardized manner,” Mike says. For example, they can move quickly “due to the simplicity of the data access and the fact that they don’t need extensive knowledge of the underlying data.”
Ash Parikh also talks about the divide between data management and real-life business needs, something that SOA and data services can help address. For example, he observes, many companies have built great data models, but these models tend to be static. “It’s great to have a model, but I also need a way to find all that information, and to make sure that information I’m finding across a multitude of these data sources – which can be varied in structures and formats — is relevant to me.” Many of these issues can be resolved at the data services abstraction layer, he says.
November 12th, 2009
Posted by Joe McKendrick @ 10:33 am
Categories: Business ROI, Case Studies, Management, SOA Events, Vendor Watch
Tags: Information Technology, SOA, U.S. Department Of Defense, Service-Oriented Architecture (SOA), Web Services, Portals, Middleware, Enterprise Service Bus, Enterprise Software, Software
A vexing issue that comes along with service orientation is figuring out who will fund the services being shared across the enterprise. Things get even more interesting in really large organizations with lots of multiple business lines. So you can imagine the complexity of service funding in something as large and complicated as, say, the US Department of Defense.
Funding, establishing user dialog, federation, quicker turnarounds are latest challenges for DoD
Speaking a a recent roundtable on government SOA implementations, Dan Risacher, staff member with the CIO’s office at the Department of Defense (DoD), says DoD is bullish on SOA, and is undertaking serious efforts to service orient its multiple systems. However, one of the greatest challenges is deciding how various services get funded, Risacher says. “In the defense department, we have a tiered structure — very high-level DoD and military departments underneath that. One of the particular challenges with SOA within an enterprise environment, whether that be a federal agency or business, you have different business units each providing their own services. Often the chargeback and the incentive models are the greatest difficulties. We’re struggling with that.”
The roundtable, hosted by Dave Chesebrough, president of the Association for Enterprise Information (AFEI), also included Matthew Swartz, branch head of Enterprise Initiatives for the US Navy, and Mike Darretta, JBoss solutions architect for Red Hat, and covered issues such as funding, integration, and paybacks.
Risacher said DoD formulated and published its SOA strategy in May 2007. The goals of the effort are to “get people to provide services on the network, make sure that those services are visible, accessible and understandable to other users, incentivize people to use them, improvise and use them, and figure out how to manage them from a network operations standpoint as well as a governance standpoint.”
There is a centrally funded model for SOA-based services that exists within the intelligence community, but Risacher says it may be a difficult model for DoD to follow. “The problem is lots of people use a service, and that makes the cost go up — but doesn’t provide any additional resources and revenues to the organization providing that service.”
Overall, however, a service-oriented approach is helping DoD speed up the application development and deployment process, and better target functionality where it is needed. “We have a concept we call ‘communities of interest,’ in which we get groups of related users together who need those capabilities to actually help define what do the services need to be,” Risacher says. “We don’t want to have to wait and figure out in great detail what those services are before we start providing them. But having that dialog enables us to provide services that are actually responsive to what people need.”
The US Navy is also taking an enterprise view of its information technology, according to Matt Swartz. The availability of the Navy Enterprise Portal, along with the Navy Enterprise Information System (NEIS) is seen as a key “initial tactical step towards enabling SOA-type services or the ability for our users in the Navy to access enterprise services.” The various systems and portals are being integrated and federated through an enterprise service bus, he says. “We see this as one day potentially being an enterprise service bus for other capabilities or enterprise SOA services across the Navy, and ultimately connect and federate with other DoD services” he adds.
These capabilities are now delivered via two platforms — Oracle Fusion middleware for NEIS and Microsoft SharePoint for the portal, Swartz elaborates. “We belive that the portal environment will allow us to bring distributed applications together, and also enable information sharing that not currently available to the sailor or the warfighter in these distributed environments.”
For the defense department, SOA has been an incremental journey, versus a huge sweep of its technology landscape, says Risacher. “We’re focusing on things that are scalable, cost effective. How do I do things in a spiral kind of capability… where I’m fielding new capabilities as I go along — rather than trying to take a big-bang waterfall type of approach, trying to figure it out all up front in the requirements phase.”
There is enormous cost-savings potential as well, especially from an integration standpoint, he added. “For large DoD systems, we often find that each connection costs $1 million a year to maintain – that’s not an exaggeration. When I have to go out pay one big defense integrator and some other second defense integrator to make their systems talk to each other — and inevitably something changes either in the interconnect or the data standards change — it ends up being very expensive to have a whole lot of those links. So I’m trying to get that down to where we have a much smaller set of interfaces, rather than a very large set of interconnections.”
The name of the game is faster turnaround of IT capabilities, Risacher continued. “We’re trying to influence acquisition strategy needs to focus on smaller and shorter deliverables, so we can task as we learn, reduce risks, and get those capabilities out faster. We’re focusing on standards and open architecture, and how to share some IT resources. It’s a big, difficult shift for an organization as large as defense department.”
It’s interesting to see how a large, complex organization such as DoD is wrestling with many the same issues — and sees the same kinds of opportunities as smaller, commercial organizations. As DoD and other federal agencies work through some of the issues around service orientation — such as governance, funding, federation, and security — there will be some best practices emerging for private businesses as well.
November 11th, 2009
Posted by Joe McKendrick @ 10:15 am
Categories: Business ROI, Links, Management, SOA Surveys and Research
Tags: Information Technology, Janne, Strategy, Management, Joe McKendrick
Are your investments in IT bearing measurable results? Or are the benefits more “feels-right” types of results? Perhaps IT can’t deliver measurable productivity because the measurements are wrong.
Perhaps IT can’t deliver measurable productivity because the measurements are wrong
Every time I’ve spoken to a CIO and IT manager over the past decade, one question I always ask is if he or she has been able to measure the results of programs, be it service oriented architecture, CRM, Web-to-host, what have you. And, I have to admit, I rarely hear measurable numbers — it’s usually anecdotal evidence, such as speedier processing, or positive end-user or customer feedback.
Don’t blame the CIOs, though — it’s just that the benefits of IT are inherently difficult to quantify at any high level. In this vein, Janne Korhonen just published an interesting piece over at ebizQ, explaining why it’s so hard to measure the productivity impact of information technology.
Janne quotes MIT’s Erik Brynjolfsson, who in 1993 published a landmark paper on why the productivity impacts of IT is so hard to measure: 1) measurement error due to use of conventional productivity-measurement approaches; 2) time lags in IT payoffs; 3) localized optimization; and 4) lack of explicit measures of the value of information.
We don’t seem to have come too far in the 16 years since Brynjolfsson published that analysis — at least in Janne’s opinion. He delves into Brynjolfsson’s four challenges in some detail. For example, he notes that when it comes to measurement errors — caused by outmoded ideas about constitutes productivity — he calls for “rigorous new means to measure IT productivity and output are needed to account for IT’s role in innovation and new value creation, commensurable with IT-enabled efficiency.” IT’s contribution to “operational improvements, new capabilities, new products and new markets” — long underestimated — is a good place to start.
As discussed here at this blogsite, there are benefits and gains that are either tough to capture, or tough to tie directly back to a particular IT initiative. “Business agility” is a classic example — how do you measure business agility? This is the benefit touted for service oriented architecture — how much agility is being delivered by an SOA initiative, versus other systems? The businesses at the forefront of SOA tend to be at the forefront of other advanced management practices as well.
Then there’s the whole matter of oversell, companies pouring money into IT products and services that may be, on the whole, unnecessary or overkill. Or worse yet, end up as shelfware. You don’t need to be a productivity expert to see the waste there. So you have the combined storm of hundred of thousands of dollars being spent on something for results that, if measured, will be measured against archaic productivity standards. Will cloud breath clarity into this confusion? Probably not.
It should be noted that Brynjolfsson hasn’t been entirely pessimistic on the ability of IT to deliver business success since that 1993 paper. More recently, he and MIT’s Andrew McAfee published data that shows IT making a big difference at a macro level. They observed that industries that made the greatest investments in IT during the 1990s have become the most competitive. “On average,” they said, “the whole U.S. economy has become more ‘Schumpeterian’ since the mid-1990s. [Joseph Schumpeter coined the term "creative destruction" in 1942] What’s more, these changes have been greatest in the industries that buy the most software and computer hardware.”
Again, it’s more than pouring money into products. McAfee and Brynjolfsson state that even with a lot of IT, “both innovation and replication require a combination of leadership and insight from executives. Take innovation: Many companies use IT to capture huge amounts of data from their operations, but relatively few have been able to use this data creatively.”
And it takes perceptive management to identify the technology solutions that will make a difference, and be able to effectively measure the impact of those solutions. As Janne put it:
“Not all IT projects are productive. They may even be detrimental to the business, but misaligned incentive schemes and other structures sustain non-optimal IT decision-making with predominantly short-term planning horizon and focus on operational and cost efficiency. IT investments should be judged by their overall bottom line impact, including not only cost reductions and efficiency gains but also the indirect impact that IT has on increasing business effectiveness.”
The bottom line is that there has never been an expectation that IT would be solely responsible for a company’s rise or fall. Adroit management, supported by the right IT tools, makes the difference. A company that smartly and innovatively leverages its IT in new and creative ways will move to the head of the pack. And, thanks to IT, you don’t need a workforce of thousands to do so. And we need to measure these changes in more holistic ways.
November 9th, 2009
Posted by Joe McKendrick @ 6:52 pm
Categories: Business ROI, Management, Standards Watch, Vendor Watch, Web 2.0-Enterprise 2.0, Web Services
Tags: Enterprise Mashup, Joe McKendrick
Kudos to JackBe’s Luis Derechin for his refreshingly candid admission and personal journey of discovery in an effort to arrive at the definitive definition of “enterprise mashup.”
You may recall that last spring, following a TV news interview, Luis was not happy with the explanation he gave to describe enterprise mashups. JackBe sponsored a couple of contests, along with a lot of discussion among practitioners and analysts.
Here, at last, is the working definition Luis and his team have arrived at:
“Enterprise Mashups are secure, visually rich Web applications that expose actionable information from diverse internal and external information sources.”
Wait — that’s not all. The JackBe crew also sought to answer the question of “why” people need enterprise mashups. They didn’t want enterprise mashups to be solutions in search of problems, as has been the case with many a technology initiative:
“Poor decisions are often made because decision-makers do not have the right information at the right time. Enterprise mashups deliver new insights and enable better decisions through personalized access to the right, real-time information for the specific problem at hand.”
And finally, the JackBe crew also addressed the “how” aspect — as in how enterprise mashups can be created:
“An enterprise mashup platform is a technology suite that enables the rapid, collaborative, user-driven creation of Enterprise mashups without the complexities, costs and risks of traditional information integration projects.”
In this last passage, the user-created aspect of enterprise mashups are included in the definition. This is where mashups can potentially deliver business benefits, as more flexibility can be put into users’ hands. And, as the “why” part of this definition shows, enterprise mashups put decision makers in touch with performance data from across the organization. The greatest challenge to delivery of information at this time is the time it takes to prepare and deliver reports. Let’s give end-users the tools to quickly and configure their interfaces to back-end enterprise applications and data.
November 6th, 2009
Posted by Joe McKendrick @ 2:42 pm
Categories: Links, business process management
Tags: Business Process, BPM, SOA, Modeling, Service-Oriented Architecture (SOA), Operational Planning, Research & Development, Business Process Automation, Enterprise Software, Web Services
Business process management (BPM) and SOA don’t have to live in two different worlds. In a new Q&A tutorial, enterprise architect extraordinaire Todd Biske provides practical advice about pairing BPM modeling tools with service oriented architecture.
The key lies in the registry/repository of services created to support SOA: “One of the most important things to consider is the ability of the BPMN tooling to take advantage of service metadata that exists in a registry/repository,” Todd explains. “Whether modeling within the tool is being done by process analysts or by developers, the ties back to your service repository are important.”
Then consider the two roles that engage in this collaborative process:
Process analyst: These individuals may be working with a BPMN model, which will consist of flow objects, connecting objects, swimlanes, and artifacts. The two items that have relevance within SOA are the activities (part of the flow objects), and the swimlanes, which represent ownership boundaries of functional domains, Todd points out. “If you have this taxonomy in your service registry/repository, it would be great to have it accessible to you during your modeling efforts.” Service invocations should be shared across processes, and integrated into the registry/repository.
Developer: It is up to these folks to “take that model and turn it into something that can be managed by the runtime BPM engine,” Todd explains. Developers ensure that automated information-generating activities are correctly mapped to the message flow, via the connection between the service registry/repository and the BPM tool.
November 6th, 2009
Posted by Joe McKendrick @ 8:43 am
Categories: Business ROI, Data managemetnt, Enterprise Architecture, Event processing, Management, SOA Events, SOA Surveys and Research, business process management
Tags: Event, Service-Oriented Architecture (SOA), Web Services, Pricing, Strategy, Application Integration, Middleware, Enterprise Software, Software, Marketing
Complex event processing — now made possible by service-oriented architecture principles — represents the next stage of business intelligence. However, much work needs to be done to reach this capability.
Complex event processing requires a different mindset and skills
A ebizQ’s latest SOA in Action conference, I had the opportunity to moderate a session with Gartner’s Roy Schulte, CalTech’s Dr. Mani Chandy (CalTech), and IBM’s Frank Chisolm in an informative discussion about applying event processing as a strategy for businesses seeking to remain competitive in the years ahead.
However, Roy cautioned, event processing capabilities don’t just automatically pop up, even among companies with the most advanced BI infratstructures. “The way you get your systems to be more smart fast and agile is by having the systems designed correctly, and in most cases that means more use of the event processing design methodology,” he says. “You can’t just take a conventionally designed system and just speed it up to accomplish the goals that people want to do.”
While the technology now exists to build CEP, the methodology requires a different mindset among companies. “The limitation that we have today is that there are not enough people around who understand how to design systems that operate in this fashion,” Roy says. “They don’t understand continuoius intelligence or complex event processing.”
Complex event processing requires continuous streams of information from multiple sources. The good news is that CEP need not be so complex, and, in fact, over the next few years, systems that sense and respond to events will be as commonplace as business intelligence systems are today.
Mani, considered one of the early visionaries of complex event processing, said the “PC-cubed” formula (three Ps and three Cs) will drive CEP forward over the next few years:
- Price – The price of managing data sources will continue to drop.
- Pervasiveness – Sensors, such as mobile phones, have become pervasive.
- Performance – “Enterprises have access to immense computing power that can be harnessed through event processing,” Mani says. And now, “parallel, distributed, and cloud computing create ideal environments for event processing.”
- Celerity - “Businesses and consumers demand swift action,” Mani points out. “You expect to be notified immediately if your plane is late.”
- Connectedness – The world is more interconnected. Your company may need to respond immediately to an earthquake in China, a flood in India. Event processing applications help detect events all over the globe.”
- Complexity – “Businesses have become more complex, and expect IT to help with increasingly complex problems.”
As if laying out the case for complex event processing as “PC” doesn’t clarify enough, Mani also explained how a mnemonic — A, E, I, O, U (but not sometimes Y) — describes the CEP phenomenon:
- A — Adaptability: “The event pattern has two advantages, one is loose coupling for application integration, and the other is sense and response,” Mani said. “App integration because producers and consumers are coupled in a loose way without knowing about each other. Its easy to add or change the producers and consumers of a system. With the sense and respond aspect, an example is scheduling railroad crews — a complex problem, a sense-and-response problem. Because unscheduled events happen all the time, smart railroads are using event processing to adapt.”
- E — Exceptions: “Computers have to analyze torrents of data to extract nuggets,” said Mani. “These nuggets are the events that require a response. A characteristic of smart people and smart systems is that they mange by exception.. they perform continuing operations effectively, bit they continue to detect and respond exceptional situations. Event processing helps separate the critical from non-critical.”
- I — Instrimentation: “Successful businesses manage exceptional events successfully,” according to Mani. “Event processing is used to instrument and monitor the exception and the normal. You will see a rapid rise in business instrumentation and event processing for to improvement of business activity in the next decade.”
- O — Outside: “1960s-90s enterprise IT dealt with mainly IT inside the enterprise. Now the enterprise is responding the events externally,” said Mani. “The enterprise monitors actions by the government, its competitors, its suppliers, and its best customers. The ability to sense and respond to events out side the enterprise using event processing is a significant competitive advantage.”
- U — Unanticipated events: “Enterprises develop event process applications to handle certain types of that they expect, and must also deal with conditions that they don’t expect,” Mani explained. “Any significant deviations are detected by an event processing application which then sends information about this deviation to appropriate people before the analysis.”
Dr. Mani Chandy and Roy Schulte have just puiblished a new book on the subject, entitled “Event Processing - Designing IT Systems for Agile Companies.”
November 4th, 2009
Posted by Joe McKendrick @ 9:34 am
Categories: Business ROI, Enterprise Architecture, Management, SOA Events, SOA Surveys and Research, Web Services, business process management
Tags: Gartner Inc., SOA, Service-Oriented Architecture (SOA), Web Services, Middleware, Enterprise Software, Software, Joe McKendrick
Pro-SOA view: SOA is the greatest thing since sliced bread.
Anti-SOA view: SOA is toast.
SOA moderate view: Let’s just worry about baking service orientation into our business processes where we can.
I just had the pleasure of hosting a Webcast keynote with Gartner’s Yefim Natis over at the ebizQ “SOA in Action’ event, and Yefim did a great job of popping the myths around SOA — not only among the naysayers, but among the over-optimistic SOA proponents as well. Instead, Yefim urges a balanced middle course with SOA, with a serious emphasis on what it can do for the business.
Here are the 10 most common myths — promulgated by both SOA “fanatics” as well as naysayers — that need to be put to rest (no pun intended):
SOA Fanatic Myth #1 - Services were invented in the IT department and are spreading out to the business. This myth assumes that SOA architects and designers “will be bringing solutions to the business that the business itself couldn’t invent,” Yefim says. However, he observes, “encapsulated functions have existed in business forever. This is how business is structured.” Instead, SOA is about improving the “ability of software designers and software architects to model the real world better. Software is not bringing the solution to the business, its better understanding the business.”
SOA Fanatic Myth #2 - SOA applications are assembled from pre-built components. “SOA is not a Lego game,” Yefim says. “Although service oriented systems indeed include encapsulated components, or services, they also include clients, batch components which are not service oriented, and include legacy systems that need to be connected to.”
SOA Fanatic Myth #3 - Sharing or reusing application logic is the main benefit of SOA. “In reality, a successful environment will have reuse of about 30%, so that is a ballpark number where you should feel good about your level of reuse,” Yefim says. “If that’s the case, it means many organizations will have less than 30% — so reuse is not the primary benefit, although it is one of the benefits of service oriented architecture. There are many other things, such a making your internal architecture more manageable, having greater extensibility, and applications that function a lot better when they are service oriented.”
SOA Fanatic Myth #4 - SOA eliminates the need for application integration. No matter how effective your SOA infrastructure, you’re still going to need enterprise application integration, Yefim says. What SOA does do is “introduce a consistency to the architecture, as well as tools and standards that help application integration.”
SOA Fanatic Myth #5 - SOA reduces the cost of IT. It may help reduce IT costs in the log run, but early on, “investment in SOA costs in fact costs more,” Yefim says. “Not because SOA is more complex, but just because when you do something new, you have to understand new approach, you have to train people, you have to buy new tools — and that all is costs.” What SOA does do is “shift the costs, distribute the costs differently.”
Yefim also took the occasion to refute some of the negative things also being said about SOA as well. Here the top five naysayer myths about SOA:
SOA Naysayer Myth #1 — SOA introduces new complications and new problems. “That might be true, depending on what you were doing before,” Yefim says. “After all, complications and problems are all relative to prior experience.” However, he points out, “most issues that have to do with deploying and establishing service-oriented systems are not issues of SOA; they’re issues of distributed computing, or of modern grid based computing networks.” Without SOA, he says, companies would “probably be facing the same complications and issues.” At least SOA provides a more consistent approach to tackling these problems.
SOA Naysayer Myth #2 — SOA is nothing new, it’s hype, it’s taking old wine and trying to sell it in a new bottle. SOA is merely a set of coarse-grained remote procedure calls (RPCs). SOA builds upon earlier models of distributed computing and RPCs, but it’s something different, Yefim points out. “SOA is intended to address a business topology of the business functionality of the application, whereas RPCs were intended to simply distribute an application.”
SOA Naysayer Myth #3 — SOA is doomed because Web services don’t work well enough. This widely held misconception is based on the view that SOA is entirely based on SOAP. “There’s nothing in common between the two, yet people confuse SOA with SOAP. SOA is not about Web services — Web services is one of the ways of establishing connectivity between the clients and the services of SOA.”
SOA Naysayer Myth #4 — SOA is hard to sell because the business can’t see the benefits. This is probably true for basic-level SOA, but as more companies move into advanced SOA, business benefits will become more apparent, Yefim says. “After all, SOA is an architecture, and the business sees software as a means to a goal, rather than the goal in itself.’ However, as SOA begins to support new initiatives such as event-driven processing, business awareness may grow. “Event-driven SOA has very important components to it that allow direct benefits, clear benefits to business operations, to any business that wants to gain control over its overall IT information environment or wants to build situation awareness.” Event-driven SOA, Yefim adds, “is the foundation for business activity monitoring, business intelligence, situational awareness. All of these directly serve business.”
SOA Naysayer Myth #5 — SOA is obsolete, and its time to move on. Indeed, the industry is probably ready for a new round of buzzwords, Yefim says. “There’s no intrigue anymore in basic SOA. We know how to do it, it’s not talked about as much as before.” But, he asks, “What are you going to move on to? The only alternatives you’re going to find to SOA are going to be advanced forms of SOA.” [See SOA Nay-sayer Myth #4, above...]
November 2nd, 2009
Posted by Joe McKendrick @ 7:26 pm
Categories: Management, SOA Events, SOA Surveys and Research
Tags: SOA, Randy Heffner, Service-Oriented Architecture (SOA), Web Services, Middleware, Enterprise Software, Software, Joe McKendrick
SOA is still being held back by perceptions that the methodology is a set of IT best practices, versus business best practices.
In a recent presentation, Forrester Research’s Randy Heffner provided an analysis of what’s holding SOA back, and what it takes to move it forward. I had the opportunity to join Randy in an informative session on what should make SOA tick.
Here are Randy’s Rules of SOA success:
1- SOA is about good design, not cool technology.
2 - SOA is about business design, to provide flexibility for how and where via what channels we do business, to interface with any partner or customer.
3 - SOA requires big change, but take it slowly and incrementally. You don’t have to get all of SOA “right” to get value out of SOA.
4 - Good designs requires good governance. Good governance has participants, bad governance has victims.
Randy cited Forrester survey data that showed general acceptance of SOA principles within a majority of enterprises, but many pockets of trouble. About 18% to 25% of Forrester’s survey group said they are still “struggling with SOA, and they’re not going to expand further until they figure it out.”
What are they trying to figure out? Randy points out that “SOA is a diificult and complex initiative,” and to succeed requires “reframing from some of the broad messages you hear in the industry.” Companies struggle with SOA, he explains, because, first, “they treat SOA as a technology” rather than a business transformation. Second, they “treat SOA as objects and components,” and third, “they over-focus on reuse,” which is but one of the benefits.
Randy suggests seven “fixes” that can help get SOA off the narrow technology project track and onto the business services track:
Fix 1 — Use SOA to create a business model. “Use SOA based bus services to insert a layer of simplicity around the business where you most need it.”
Fix 2 — Build service portfolios, not service libraries. “The library view can be a very haphazard, amnesic way to manage services. Service developers will forget what services are out there…. We’re trying to leverage projects, and put them within this broader strategic context withoin our porfolio.”
Fix 3 — Adopt a “street-level” strategy to address both short and long-term SOA. “We need to move away from this big-bang approach to SOA.” A street-level strategy is adaptable to any shifts in the business — such as hard versus good economic times, Randy adds.
Fix 4 — Avoid the reuse trap. “Yes, reuse is a good thing, and you will see benefits. But it’s not all about reuse, it’s about the right design, and reuse is the side effect that should be happening as you’re doing good design.”
Fix 5 — Adopt a variety of SOA funding strategies. You can get SOA money in and of itself, get SOA funding for solutions that use SOA, or get it through training or R&D programs. Most SOA funding comes from solutions-oriented projects, Randy says.
Fix 6 — Do SOA governance. If a company was event doing just one or two of the 12 best governance best practices covered in Forrester surveys, it “was correlated with higher satisfaction with SOA,” Randy says. “Even a little SOA governance leads to satisfaction.”
Fix 7 — Do more SOA governance. “If you’re doing SOA right, SOA is far from dead,” Randy says.”And SOA governance will keep it on track.”
If you’re making incremental progress with SOA, then you’re creating success with SOA. And there’s a switch that happens. “All of a sudden you don’t have to justify SOA,” Randy says. “It becomes how to make SOA better is the justification, versus whether or do or not do SOA.”
October 30th, 2009
Posted by Joe McKendrick @ 8:56 pm
Categories: Management
Tags: Fame, Information Technology, Strategy, Management, Joe McKendrick
Oliver Widder of Geek & Poke fame picked up on my recent Lean IT post and illustrates where the “leanness” comes into the picture.
October 29th, 2009
Posted by Joe McKendrick @ 6:59 pm
Categories: Management, cloud computing
Tags: Silo, Enterprise, Enabling Architecture, Service-Oriented Architecture (SOA), Enterprise Software, Web Services, Software, Joe McKendrick
I just had the opportunity to moderate a panel with Miko Matsumura and John Favazza, in a rousing ebizQ roundtable discussion on trends on SOA governance. Miko pointed to the complexity of enterprises, noting the challenges of bringing the hopelessly fragmented parties within larger organizations into alignment. This is one of the objectives of good governance.
Miko points out that size matters when it comes to clouds as well. Especially when it comes to enterprise software. (Miko reminds us that the word “Enterprise” in the phrase “Enterprise Software” has come to mean “software that sucks.”)
Cloud gets particularly challenging when the organization grows, and is has fragmented into factions, silos, and niches. Adding cloud means more complexity, “yet another technology silo to maintain, integrate, secure and govern,” he says. A systematic enabling architecture is required to introduce cloud across the multiple parts of an enterprise.
One of the issues with many SOA efforts to date is that many people threw Web services out across their domains, hoping they will eventually gel into service oriented architecture. When you have different divisions or departments subscribing to their own choices of cloud services, the complexity grows.
October 29th, 2009
Posted by Joe McKendrick @ 7:15 am
Categories: Links, Standards Watch, Web Services
Tags: IPv4, IPv6, IP, Internet, Networking, Telecommunications, Joe McKendrick
The impending changeover from IP version 4 to IP version 6 won’t really be a big deal, and most people won’t even notice it as it happens. But the Internet will be running on both protocols for a while, and the head of the American Registry for Internet Numbers (ARIN) cautions that some online applications may run slow as a result. Online content providers need to start preparing as well.
In a recent interview, John Curran, president and CEO of ARIN, explained why businesses need to sit up and take notice of the impending shift that is taking place as we move from Internet Protocol version 4 (IPv4) to the more expansive IP version 6.
What’s happening is the original Internet numbering system — which assigns addresses such as 192.168.1.1 — is running out of numbers. IPv4 is a 32-bit system with four billion possible combinations. “That sounds like a lot of numbers, but it really isn’t when you think about the size of the globe and the number of devices being connected these days,” Curran says. In fact, we’re due to run out of numbers within 700 days, he warns. IPv6, with 128-bit addressing space, enables “numbering of all of the molecules in the galaxy,” he says.
As soon as the last IPv4 number is used up, every new device or site that comes along after that uses IPv6. Don’t loose too much sleep over your systems, however. Industry planners have been aware of this matter since the 1990s. Most hardware and software has been ready for IPv6 for some time.
However, Curran advises businesses to check their configurations before the changeover takes place, as glitches may come up. “We can’t actually get an IPv6 host and an IPv4 server to talk to each other, because the IPv4 server only knows 32 bits. It’s much like if your telephone was set up to only ever dial seven digits, and it wouldn’t let you dial 10. Sure you could almost have a conversation, but you couldn’t call most of the world.”
When the changeover occurs, “ISPs are going to have to start using IPv6 to connect customers,” he explains. “Then, they’re going to have to put IPv6 gateways in, boxes that work like network address boxes, to translate IPv6-connected customers to the IPv4 websites on the Internet. That will work, but that’s going to be suboptimal, because those are gateways doing the translation.” This may slow down online applications such as Skype, Voice over IP, real-time video games, which “won’t necessarily run smoothly going through those translators.”
Curran points out that the Internet will be running on two protocols for some time. “If you really want to start a business that’s Internet based, you’re going to want to take your equipment, and make it connected by both IPv4 and IPv6.”
Some businesses have more of a challenge ahead of them than others, Curran continues. While the major ISPs have been underway with IPv6, “the content providers are just beginning to work on this,” Curran says. “And that’s going to take a lot of work, and they need to enable a lot of software that we think of as the Web 2.0 software infrastructure. While all the parts may run IPv6, that doesn’t mean your infrastructure is ready.”
Consider the two years remaining to address IPv6 configuration issues as an opportunity to get a jump on the competition, says Curran. “I would recommend that people start thinking about the fact that the IPv4 Internet has a fixed size, and the global Internet is going to keep growing. What this means that you don’t want to be left behind on the fixed-size network. You don’t want to be left behind on a fixed-sized network in an Internet ‘backwater.”
By the way, the interviewer, Howard Greenstein, said it’s important to get this cautionary message out on ZDNet and other popular channels — so there you go, Howard!
Joe McKendrick is an author and consultant with deep knowledge and insights regarding trends and developments in the technology industry. See his full profile and disclosure of his industry affiliations.
Email Joe McKendrick
Subscribe to Service Oriented via
Email alerts or .
SponsoredWhite Papers, Webcasts, and Downloads
