Tuesday, July 22, 2008

Behind the Pit Wall ...

I have enjoyed a busy week in my Simi Valley office, catching up on a lot of correspondence that I have, for the most part, only lightly addressed in the past couple of weeks. Paging back to make sure I hadn’t missed anything, and to re-engage in a couple of exchanges I had let slip, how I longed for the simple days when snail mail arrived at my desk a couple of times a week.

There’s a flip side to staying fully engaged with all that’s going on across the community, of course, as each time I do re-engage I run the risk of saying something wrong or sounding foolish. And I was reminded of this as I was paging through pictures that I had taken last week at Willow Springs race track. The picture I have included here is of the car returning to the pits with the words of caution in the background – “EXTREME DANGER STAY BEHIND YELLOW PIT WALL.” How much safer it would be for us if we just stayed inside our cubicle. If only we stayed away from the debates our industry so frequently let percolate to the top.

I will not go into details of last weekend’s activities at Willow Springs – you can read about the progress being made, as High Performance Driver Education (HPDE) continues, at: http://buckle-up-travel.blogspot.com/search/label/NASA%2008’ Read the most current posting “Staying smooth! Making Adjustments!”

Behind the pit wall there was always a lot of activity. During warm-up and qualification sessions some of the better crews were calling in their cars to get tire temperature readings. When driver education was being undertaken, quite often the instructor would leave the car to swap places with the driver so as to show the student the correct racing line. At other times, friends would be anxiously waiting the return of the car so that they could get a ride, as a passenger, in one of the much higher-speed time trial sessions. And then there was the “black flag” cone where drivers had to return to report incidents and to explain what they thought they had been doing at the time. Getting the story wrong was sure to see time on the track significantly curtailed.

In our daily IT lives, much the same goes on. While much of my focus remains centered on email exchanges as I route requests from partners to key members of my company, for almost everyone else in the community there’s a growing sense of urgency around integrating product sub-sets and features, and providing access in a standard way so any authorized user coming in from the web can be supported.

And from where I sit, it’s not all that different from what goes on behind the pit wall, and frequently the chaotic scenes we witness in the IT make any race track’s pits look rather sedated. There is definitely a technology wall that is just as tangible and as prominent within IT as exists at any race track. And coming out from behind it, in pursuit of architectures and models not well thought out, can leave us looking foolish.

While I was catching up on my email I also quickly scanned a couple of IT magazines – among them, InformationWeek, a popular tabloid liberally sprinkled with “sound-bites” from the executives of major corporations. One such quote caught my eye. It was from Kirk Guttmann, the CIO of GM who was talking about the progress GM was making to significantly streamline the IT infrastructure as they try to remain a significant global manufacturer.

“Simplicity brings with it higher uptime and lower costs, and lets you focus on innovation because you have a common backbone to plug into,” Mr. Guttmann remarked. In a case of not being surprised by what was said so much as I was surprised that this was coming as news to a major engineering company like GM. Everyone knows that complexity is a function of how many moving parts you have assembled. Keep it as simple as possible, and it just may run as expected.

GM’s CIO went on to discuss the merits of standardizing on Microsoft Windows for the production floor devices, and rationalizing communications traffic to flow over just IP. He also added that GM was fully leveraging the services of major companies like EDS, Cisco and HP, and even has vendor’s experts present inside critical operations centers helping with problem solving.

None of this would be possible, I believe, without the extraordinary growth in Web services in general, and in Service-Oriented Architecture (SOA) specifically. SOA has been embraced by most of the application and solutions vendors and is becoming widely accepted as the most open, standardized way to interface to other vendors products.

You can integrate applications using services, right on the client itself. You can build new products that run on a server that execute similar services integration, but at the server level. You can throw services onto an enterprise bus and let other products extract the data contained within the service as, and when, they like. Enabling this is SOAP, a lightweight XML-based massaging protocol supporting Web services request and response messages. Once an acronym for Simple Object Access Protocol, its deployment of late has made associating it with the acronym, and with the concept of being simple, rather dated and somewhat demeaning (to what it can provide).

According to the reports coming out at the recent HP Technology Forum and Expo (HPTF&E), HP NonStop plans to support “selected open-source frameworks to simplify and ease development of Enterprise Java applications for the Integrity NonStop platform. These frameworks require a runtime, and the value proposition to the customer is to combine the simplicity of the framework-based Development model with the enterprise-scale runtime that is provided by NonStop's scalable and highly-available Tomcat implementation.”

Essentially, HP is committing to begin supporting, in early 2009, a deep port of SASH - open source support for a Java Spring Framework (for business logic and component wire-up), Apache Axis (for SOAP support), Java ServerFaces a specialized UI framework that combines the component model of Swing with the Java ServerFaces (a specialized UI framework that combines the component model of Swing with the Model-View-Controller (MVC) framework of Struts), and Hibernate (for object-relational mapping and data abstraction).

I have been a champion of SOA and Web services for almost a decade. Many members of the former ITUG community have sat through my presentations and can probably recall how enthusiastic I have been. But I have to believe that with the imminent arrival of a deep-port of SASH, the HP NonStop server will be as open and as easy to use as any other platform yet with levels of availability and degrees of scalability unknown outside of NonStop. And just as fervently, I believe with SOA we will break down the application silos that dominated our technology landscapes for years. SOA will allow us to leverage components in new ways, integrating them with other silos to create completely new applications that better meet the needs of the business.

I recently asked a HP product manager who had been close to this technology in the early days about user adoption of SOA and Web services, and his comment back to me “I am outside the buzz these days, but I think it has already tailed off.” Or has it? My suspicion is that this is a technology that has found a home in the vendor community as it makes the requirement to support other vendor’s products a non-issue. And perhaps this is the real story. Its lack of visibility may simply be due to its transparency, as its usage has become ubiquitous. Perhaps we shouldn’t be looking at the application developer to embrace SOA as much as we should be challenging our vendor partners to open up their products as services!

With SOA, how much longer will we heed the signs and stay sheltered “behind the pit wall.”? Is there really “extreme danger” on the other side of the technology wall? Could we really be pursuing something completely at odds with what the rest of IT is pursuing, only to leave us looking foolish? I just don't think so! What are we waiting for – with proven technology and applications running for almost a decade, what more are we looking for? Its protocols are simple to comprehend and its concepts easy to grasp.

As the GM CIO reminded me, if it “lets you focus on innovation” then isn’t this what our business lives are demanding of us? If there is any perceived risk remaining for those of us still undecided, then our reluctance could become a serious impediment to the business we are employed to support and it may be us who end up being tossed over the wall and discarded!


Ron Thompson said...

Richard - Thanks for the update.

At CAIL we believe SOA and SASH are important too.

However, since moving to Web Services and SOA is typically a strategic initiative with a compelling business value proposition, many people with strong technical skills appear to find it challenging to relate to evolving systems in this direction. Further, since this is all about "exposing information", it is counter intuitive in the NonStop systems environment. As you can appreciate, the proprietary nature of the NonStop platform has been a huge advantage in delivering very high systems availability as well as mitigating security and other potential disasters. However, it's also problematic in making NonStop information services more integral in enterprise IT infrastructure and being included in initiatives to address new business needs.

As we both know, utilizing Web Services and having a NonStop SOA strategy is important to help address this situation.

If you have suggestions to increase the awareness of the importance of moving NonStop systems forward in this direction, please let me know.

Ron Thompson said...
This comment has been removed by a blog administrator.
Ernie Guerrera said...

An industry analyst asked me just today, "SOA was a hot topic a couple of years ago and has been widely accepted by industry, is it still a hot issue?". I replied that it is a very prominent topic with the HP NonStop community, we're an ultra conservative bunch!

We can all attest to the ever increasing rate of change, especially in the technology sphere. Standards such as SOAP,HTTP,SSL, and XML help to preserve your investment in Web Service from changing environments and platforms.

At NuWave Technologies we've been promoting and evangelizing SOA and Web Services within the NonStop community at every opportunity. We encourage all architects to include their NonStop applications as active participants in their SOA strategy.

I agree with you Richard - "It's time to step out from behind the wall..."

Richard Buckle said...

Editors Remarks -

Please note, the additional comment from Ron Thompson was deleted as it was an (accidental) duplication for which I take responsibility.


Sami said...

Where services become externalized via the web, then there are substantially bigger concerns. When it comes to securing web services then it is a different story – you can secure the connection, add authentication etc. but there is semantic security concerns which people don’t talk about.

Think of electricity as the ultimate service; the public utility will be able to tell you that the electricity being delivered is 110V 50H and your socket is rated 2amps. They don’t know what you’ll plug into it, a chainsaw, PC, light bulb or nothing. They don’t know how many watts you’ll use ahead of time. SOA security products give you a grounded socket – but if you connect a chainsaw and chop a body into little pieces, they wouldn’t know about it. With data security, people who authoritatively own the data are liable to ensure its legitimate usage.

Should account information get sacrificed through a service offered by the NSK, you can’t just claim ignorance like the electric company could. But fundamentally, service oriented is decoupling of the publisher of an application service from the subscriber of the application service – much like the electricity and the chainsaw. Ultimately, if you’re going to expose services, you’re better off exposing parts of it to a secondary environment which is better aligned with the subscriber of the information (and possibly controlled by the subscriber of the information).

That way, if someone plugs in a 5amp storage array to a 1 amp socket and blows the circuit, you’re not impacted, if the electricity needs to be 240V 60H instead, they have a transformer in place and the service is provided in the framework of application(s) that will consume it.

TB said...

I agree that securing the service (or "adapting the power client to the power socket") is important.

However I would think that there are many cases where it is sufficient to do the "filtering/securing" on the NonStop rather than on a front-end system.

As long as you are not opening up your SOA service via the Internet and as long as you use proper access control (user name/passwords, firewalls, ...) you *are* in control of who accesses your system and that can ensure proper coupling of systems.

I also think a direct connection has benefits as it reduces complexity and increases uptime of the service.