IT search and SCM search may together bridge the design time-run time divide

Productivity improvements in software development and deployment strategies will ultimately have to reckon with the lingering lack of feedback between design time and run time.

Software is still a hand-off affair, with developed applications getting tossed into production with little collaboration between the builders and the operators -- before or after the hand-off.

Things could and should be different. Thanks to search-based technologies and services now entering the market, we may be on the verge of a new productivity boomlet that leverages more needles from more haystacks.

With proper access to information about how code actually behaves in real-world use, developers could better produce reliable applications and infrastructure. Architects and systems operators could better anticipate how to meet the demands and service level agreements (SLAs) of quickly provisioned applications if they had greater visibility into the hit on resources -- and potential disruptions -- from newly minted applications and services. Virtualization will only exacerbate the deployment complexities.

Wouldn't it be beneficial then if the information about what goes on "on the other side" were made available proactively to each side of the equation? Search functions applied directly to both sides of the development and deployment fence would allows those open a bright new window into what remains murky and mysterious from the outside.

Developers with proper access to indexes and meta data could use search to quickly find highly specific information about run time environments and stacks as they write and test their code, and as they seek out the best components, objects and methods suitable for specific runtime scenarios.

Conversely, operators faced with slow-running applications -- or worse -- could search into the source code for clues about root causes of glitches, and much easier and faster identify and remediate the problems. They could also clearly point out the impactful issues back to the development and test teams, to prevent the glitch from recurring in the future.

We're already seeing a great deal of value from operations-side search, and the extension of that value due to platform approaches, APIs and open collaboration. Splunk is providing a path on IT search as a platform. [Disclosure: Splunk is a sponsor of BriefingsDirect podcasts, including this one on Splunk Base.]

Other vendors are emerging to fruitfully employee search to the source code management (SCM) space, such as Krugle. Krugle offers a search benefit for open source assets, as well as enterprise development assets.

Now when we can jibe software characteristics and collaborate across the design time-run time divide based on the type of insight that the likes of Splunk and Krugle provide, well then we'll be in a better software age. It may be sooner than we think.

I'm dying to blog on the NYT story, but it's nothing to lose sleep over

The blogosphere is having a field day with The New York Times page one Sunday story on killer blogs. (They came from Africa via South America, and are moving north from Texas right now!)

Funny that the passing of NRA chatterbox Charlton Heston (Let my Ammo Go!) was the NYT story for metro edition, replacing the blogs kill story from the national edition on page one.

So let's honor Charlton by taking a lesson from the NRA: Guns don't kill people, blogs do.

Or perhaps it's, Blogging doesn't kill people, computers do. (I'll give up my laptop when you pry it from my cold, dead hands!)

No, no, wait ... it must be: Heart attacks don't kill people, Mike Arrington does ... or wants to, at least Demo, mainstream media, CNET, and all the other bloggers who take speculative investments and still don't put in the torturous hours he does.

Let's hereby make today, National Tuck a Blogger In For a Nap Day. Sweet dreams, Mike.

WOA may soon eclipse SOA as most impactful business transformation agent

In a recent blog post I questioned whether services oriented architecture (SOA) was driving substantive transformation inside of enterprise IT. My conclusion is that something is not quite right in SOA-ville.

The uptake of general-purpose service enablement is by no means a hockey stick trend line. The adoption patterns some five years into the SOA evolutionary path do not show a "slam dunk" demand effect. The role, impact and importance of SOA is, in fact, ambiguous ... still. Many see it as merely an offshoot of EAI, rather than a full-blown paradigm shift.

Meanwhile, some other trends that do demonstrate more of a hockey stick adoption pattern -- social media, Ruby/Phython, RESTful interactions, and RIAs -- are worth a fresh look in the context of SOA. The new kids on the innovation block are experimenting at break-neck speed with social media, social networking, Ruby on Rails, SaaS, Python, REST and the vital mix of rich Internet application (RIA) approaches.

Something is going on here that shows the compelling attraction of better collaboration and sharing methods, of self-defining social and work teams, of faster and easier applications development, of not moving old systems to the Web but just moving to the Web directly, and the recognition that off-the-wire applications with fine UIs are the future.

A lot of these issues surfaced in a face-off last night between Salesforce.com CEO Marc Benioff and SAP Chairman Hasso Plattner.

So who's on first, SOA or Web oriented architecture (WOA)? These Web-facing trends for the time being may remain outside the strict boundaries of enterprise IT -- but they are of great interest to developers, ISVs, welling Web 2.0 services start-ups, and cloud compute purveyors.

These technologies and techniques are also clearly on the radar of forward-looking innovators inside of businesses large and small. Indeed, those non-IT influencers inside of corporations with a keen eye on the all-important Internet growth opportunity are the constituency to win over, and they are not sold on SOA.

If these methods and tools work for a handful of developer entrepreneurs in proverbial garages with credit-card balance-sized investment requirements, then why wouldn't the same solutions be scalable and relevant to the more established business world? Reaching customers quickly with compelling products and services that exploit and leverage the Internet -- this is the same for General Motors, Sprint and Dick-and-Jane startups alike.

The startups often have advantages -- because, among other things, they don't need a SOA, they don't need to integrate with 15 different back-end systems, they don't need to wield the political power inside a bureaucracy necessary to get anything done. Success requires the best of start-ups and the best of what large, well-capitalized corporations can do. But the balance may be shifting to the fleet and Agile side of the equation.

So I'm wondering now whether the window for holistic SOA deployment and value, as it has been classically defined, is being eclipsed. Is it possible that Web interfaces and data disintermediation for legacy applications will be enough? Is it possible that exposing the old applications, and reducing costs of IT support via consolidation and modernization is enough?

In short, is the path of least resistance to business transformation one that necessarily requires a fording of the SOA stream? Or is there a shorter, dry path that goes directly to Web oriented architecture? Is SOA therefore the impediment or empowerment to transformation on the right scale and at Internet time?

Is it better to seek business transformation, or perhaps to seek just enough transformation that creates better services for my employees and customers, ones that rely on the Web as much as possible? And if you don't need to go full-bore SOA on the infrastructure side to enjoy lower cost with better extension of application logic and data value, they why do it? Or why do it first?

And if you can build new applications of code, not components, and the interactions are all loosely coupled from start to finish, and the Web GUIs are what become automated -- rather than the middleware -- then doesn't that make sense, too?

What seems most important from the legacy IT installations is better access, control and extension of the application-specific data. And we can do that without full-bore SOA. And we can access that data from these WOA applications.

Maybe we don't really need a unifying theory of datacenter assets and resources after all. Maybe we can recognize that particle physics is particle physics and gravity is gravity, to use a matter-of-fact analogy. Why boil the ocean, when you can fry up a few fish and serve them up fast to the highest bidders?

I'll be seeking answers to these questions next week at the IBM Impact WebSphere conference in Las Vegas. The same questions will no doubt be on a lot of minds, and as well for those evaluating Oracle, BEA, SAP, HP, and Microsoft when it comes to SOA and WOA values.

I'm seeing a lot of good productivity being created from both legacy modernization and new Web development-and-deployment efficiencies -- and they are by no means mutually exclusive. Indeed, data integration advances and Web oriented architecture together may be the real SOA adoption path.

So let's keep an eye on how social media and networks enable workers inside of companies and users outside of companies to relate in ways that help them find what they want and what they need -- and to with quite impressive ease combine and unite as teams -- for fun and productivity. Business process efficiency may come from business-oriented social networks than from business analysts-driven services repositories and governance-enabled policies engines.

And composite applications may come from rapid Ruby development and Agile team practices -- perhaps deployed lickety-split to a public or private cloud -- than from a BPEL orchestration approach.

Services reuse may not matter as much as the kinds of use that drives constant iterative improvement on Web-facing online widgets and mashups. The real goal is to get work done and to make business and consumer services quickly and dependably available to the online and physical markets. For these real results, is SOA an impediment or empowerment?

SOA's aims have been worthy -- light-weight development, fleet compositing of services and applications, easily customizable processes, flexibly deployment options, reduced total costs, and legacy assets extensions. But there does seem to be more than one way to skin a cat.

ZapThink's Linthicum takes reins as CEO of data services provider StrikeIron

Service Oriented Architecture (SOA) consultant and author Dave Linthicum has taken over as CEO at data services provider StrikeIron, just six months after Linthicum sold his consulting firm to and became a managing partner of SOA analysis firm ZapThink.

On April 2, Linthicum was identified as CEO of StrikeIron in an article on SysCon.com, "RIA, SOA & Web 2.0 Mashups - Mash What?" StrikeIron is also conducting analyst briefings this week on Linthicum's new role as new CEO, though no news releases have apparently been issued.

Linthicum will continue as a ZapThink contributor and associate, said Ron Schmelzer, ZapThink managing partner and senior analyst. "Actually, it's a very positive thing happening.

"Technically, Dave Linthicum is still a ZapThink contributor and associate. We had negotiated something as part of our acquisition that would allow him to also serve as a CEO if an opportunity so presented itself. And one did. So, we're all still one big happy family,"said Schmelzer.

“I’m still a ZapThinker at heart, however I also have passion around what StrikeIron is doing and wanted to be a part of it,” said Linthicum. “I loved working with/at ZapThink. I will still be a contributor, adviser, and friend of ZapThink.”

Linthicum has offered his expertise on Enterprise Application Integration (EAI), SOA and Web 2.0 through speaking, consulting, advisory services, and prolific blogging and writing. In September, ZapThink acquired The Linthicum Group, making its founder a major partner in the SOA services firm.

Before forming Linthicum Group, he had been the CEO of BRIDGEWERX, former CTO of Mercator Software, and has held key technology management roles with a number of organizations including CTO of SAGA Software, Mobil Oil, EDS, AT&T, and Ernst and Young.

StrikeIron provides several on-demand web services offerings, mostly for data integration functions, as well as provides a marketplace for web services.

Apple makes headway on PC vs Mac front, but isn't that the old war?

The writing is clearly on the wall. The iPhone will grow into a significant enterprise end-point role, and OS X Macs will quickly advance beyond the now 20 percent share (estimated) of the total non-enterprise fat client compute device market. This is all but done.

Problem is that Apple is winning in the old war -- the PC vs the Mac, and the smartphone vs the mobile Internet device (MID) battles. The larger, more long-term opportunity has moved upward and outward into the realm of the services cloud. Becoming the funnel through which to acquire, access and pay for the cloud-spewing services is the new war. Client hardware isn't going to matter that much very soon, and will likely become free.

Just as Google Docs gains an offline capability, more of what will make people and workers productive will be what they get as pure services from cloud-based hosts. The next war is the cloud war, and the battles will be fought around software as a service, desktop as a service, integration as a service, infrastructure as a service, platform as a service, development as a service, content management as a service, and so on.

The new money will made through a combination of access subscriptions, direct payments for digital and media objects downloads, advertising, revenue sharing from online retail transactions, and B2B lead generation motifs.

Apple is in a good position to grab a portion of these revenues, but only a portion. Google is in a better position. And the Microsoft-Yahoo conglomeration may be in the very best position, but nothing is set in stone.

That means we should expect quite a bit of news out of Apple soon that has nothing to do with client-side hardware, and much more to do with the iTunes funnel and the .mac services cloud.

Microsoft seems to gets this. Because it does not have a client hardware business (mice and keyboards not withstanding) it can race to the next big thing on software, better than, say, Dell. Microsoft has all but given up on the the fat PC business for its future growth. Fat PC clients are a maintenance business now for Redmond.

As long as the packets make it down to the end point and get rendered, Microsoft can find new ways to grow, which are all about the cloud, integrated services, single sign on, virtualized CALs, and advertising. They call it software plus services, but it's all about the services and the dollars.

Microsoft may lose the installed Office business cash cow, but it can gain far more variety of services ... with ultimately a larger addressable market. Microsoft has figured out, thanks to Google, that the Internet business is bigger than the PC business. And these services may well represent a 50-year business trend line, instead of the fat client 20-year business that is now topping out.

Apple surely gets this too, and it's already engaged accordingly. So let me make some predictions. Apple will only have a handful more of meaningful product generations on client-side hardware. Yep, that's right, the iPhone and the Air are the beginning of the end, just because there's not too much more innovation needed down there in the hardware space. Please just add more flash memory capacity and build in the multi-protocol broadband network connectivity to the chip, and we can wrap it all up.

There's only about two to three more years left in the client hardware innovation business before the end-points go pure commodity, even with Apple's intellectual property. The hardware becomes a basic catcher's mitt for the packets, a single chipset that grabs the several important signals and processes them into a basic Web UI and supports the runtime, virtualized most likely. I, for one, don't want to see native iPhone apps; just use the browser and great UI.

But the software layer on top of the hardware, now that's a different story. And it's not a Windows domination segue guarantee, no sir. Too much baggage to support. Microsoft needs a standalone lightweight client story, and neither Vista nor CE is it. Microsoft needs to practically start from scratch on the client software of the future.

And so Apple needs to exploit this "window" of opportunity, and to take iTunes to a much larger role: The new lightweight operating system for the modern cloud services and commerce end-point. This new layer can very quickly emerge from iTunes-as-cash register for music version -- and grow into the everything else under the sun as a service (and cash register) layer.

And that's why Safari on Windows is a massively important campaign for Apple. For Apple to be a player in the cloud-based future, it must parley its iTunes hegemony into a Safari critical mass -- and that has to come at the expense of Internet Explorer and (sorry to say) Firefox.

Next, Apple will then need to munge together Safari and iTunes into a uber client layer for cloud computing-generated services reception and payments -- on mobile, PC, MID, anything that can catch the packets and support an iTunes browser. This is the funnel play, and Apple probably can do it better than anyone.

And so then comes the big question. Will Apple use this new software client model to make the services tie-in closed, open, or how open? Will Apple try and do on the Safari/iTunes client model what Microsoft has so far failed to with Windows? Will Google keep Apple open enough on all of this?

Microsoft, with the massive Yahoo audience it may soon own, will try and hold on to the client software chokepoint -- even as Apple makes a mad dash for it. This is the new war, and it has little to do with the difference between a Mac and a PC. It about both and how they access the clouds.

I suspect an Apple-Google partnership could outfox the Microsoft-Yahoo hairball, and that the Safari-iTunes-Android trifecta looks pretty interesting as the new client platform. What do you think?

WSO2 launches Web Services Framework for Spring 1.0

"Contract first" or "code first?" Spring developers now have a choice with WSO2's release of Web Services Framework (WSF) for Spring 1.0. The new WSF/Spring 1.0 integrates the Apache Axis2 /Java Web services engine into the Spring Framework, giving Spring users full control from within the Spring configuration model.

The existing SpringWebServices (SWS) within Spring supports Web services through the contract-first model, by which users start with XML schema and WSDL definitions of their service. WSF/Spring 1.0 adds code-first support, by which users can start with existing Spring beans and offer them as Web services with a simple Spring configuration.

Paul Freemantle, co-founder and VP of sales at WSO2, the open-source SOA company located in Mountain View, Calif., and Sri Lanka, explains why this new feature is important in his personal blog:

So how does this compare to Spring Web Services? Well, the first thing is that SWS is mainly about contract-first. And, while contract first is an excellent practice, there are times when it is not appropriate - for example, it may be simply too much effort for a simple first web service. WSF/Spring supports the POJO programming model simply and effectively, and generates the WSDL automatically from the beans you expose. (WSF/Spring does also expose contract-first). The second reason is simply that some users want to use Axis2. Axis2 is a very full featured and interoperable toolkit that does support some extra standards not yet available in SpringWS such as WS-SecureConversation, WS-Trust, WS-Policy and WS-ReliableMessaging. Axis2 also takes a very different approach to enabling these standards using the module approach rather than direct wiring of handlers.

WSF/Spring 1.0 is released under Apache License 2.0 and is based on the open source Apache Axis2/Java Web services engine. Key features include:

• Support for the WS*- stack, including WS-Addressing, WS-Policy WS-Security, WS-SecurityPolicy, WS-ReliableMessaging, WS-Eventing, and SOAP Message Transmission Optimization Mechanism (MTOM).
• Inversion of Control (IOC) container support enabling Spring services to be exposed through an IOC container, as well as support for editing the Axis2 booting configuration through the IOC container.
• Automated WSDL generation via the Axis2/Java code generation tool.
• Querying service support.
• Method exclusion in Spring beans, allowing developers to have fine-grained control over which methods are exposed as Web service operations.
  

WSO2 has been making the news on a regular basis lately. In mid-January, it introduced its Web Services Framework for Ruby 1.0, building a bridge between Ruby-based applications and enterprise-class Web Services. Later in January it launched its Mashup Server 1.0, which combined JavaScript and Web services. [Disclosure: WSO2 has been a sponsor of BriefingsDirect podcasts.]

WSF/Spring 1.0 is available for download today, and carries no software licensing or subscription fees. Support is available from the WSO2 site.

We know SOA depends on cultural shifts, but -- like the weather -- we still don't do much about it

Recent observations on SearchSOA.com on lack of meaningful SOA adoption suggest that the technologies and techniques have amounted to but a mere improvement on EAI. Some conveniently calling it EAI 2.0, but admit the effects are not yet wide nor deep.

We have yet to see SOA adoption lead to substantive transformation, surveys and primary research will no doubt indicate.

The acknowledgment that SOA requires top-down, bottom-up, organizational and behavioral, ie "cultural," change to proceed to its potential is well documented and debated. We have come back to this topic again and again, for example, on the BriefingsDirect SOA Insights Edition analyst-powered podcast series.

So let's recognize that a higher purpose is at work here, and that SOA is a subset -- not even a leading driver, perhaps -- of the end-game. Also augmenting and influencing the IT transformation journey in addition to SOA are several mega IT trends and shifts (in no particular order): SaaS, RIA/mashups, virtualization, cloud computing, open source adoption, ITIL adoption, business process outsourcing, applications modernization, data center consolidation, SAN adoption, BI, BPM, master data management, etc. etc. etc.

There are great new tools and effects that can make IT perform better. The tech folks obviously have their hands full with them, and are often expected to implement under the "do more for less" ongoing mandate, the unfortunate business-side takeaway from Moore's Law.

But these IT efficiencies are the means, not the ends. The end-game is business transformation. Contingent to and in coordination with that is IT transformation. The relationship between the two is intrinsic, interdependent and highly variable -- from enterprise to enterprise, IT department to IT department -- often an enigma in motion. While the IT trends deeply affect the trajectory of the IT-centric transformation, they to do necessarily have an understood or appreciable influence on the business transformation processes.

Frankly, it's all too complex, too unwieldy, too unmanageable -- this bridging of the "business side" with the "IT side." People and passions play a huge role, too. Agendas get crafted. Sides are taken. Leaders and followers emerge. Politics permeates the process, regardless of how well the IT performs. And then any means to meaningfully simplify the complexity (tactically or strategically) become themselves highly complex. And so on. And so on. Transformation remains a distant vision.

There remains therefore an ongoing, pernicious reinforcement gap between the change agents of IT, the change agents of business requirements, and the means to engender change in cultures, groups and individuals. In other words the politics of change in large, complex organizations remains a mystical, quizzical patchwork of leaps, lunges and stumbles.

Let's not necessarily blame SOA or IT, any more than we should blame the rain. SOA in of itself is not enough to overcome the many obstacles on the path to ongoing and effective business and cultural transformation.

And yet, companies do succeed. Profits are made. Solutions are crafted and delivered to markets. Buyers keep buying, and workers keep working. Productivity seems to emerge and proceed at a certain scale, at the right level of decentralization. They say our brains are constructed to work best in close groups of 8-10, and to seek cooperation in larger groups up to about 140. Family and village are the scales we've been designed for. People therefore naturally seem to gravitate back to the scale that works, and perhaps even subconsciously resist moving beyond the perceived scale (and perhaps natural order) that actually functions for them.

There's a fascinating new essay by Paul Graham, "You Weren't Meant to Have a Boss," that relates this to developers and software development, but there may be a larger lesson in it, too. IT is great and keeps getting better by leaps and bounds, but biology and evolution are destiny. IT needs to line up behind this fact, not seek to side-step it -- or worse, ignore it. It's not nice to fool mother nature, as the margarine commercial used to say.

Politics is the process by which groups of people make decisions. SOA's expected role and virtue is closely tied to politics. And the decisions being made by IT executives, by business management, and by the line of business implementors often have very little relationship, little in the way of interchange between the people and the processes in a natural order.

SOA's great promise is to help align people, process, and processing. But something remains in the way. SOA lacks a political context. It lacks power over the people, and so far the power of the people has not been much interested in embracing SOA. Why should they?

We in the industry have not answered this question: Why should the people promote SOA as a means for them to get their jobs done in the ways they know work best in real life. What's in it for the average bear? What are the incentives to SOA adoption for those carrying the load?

The politics of SOA needs to succeed if SOA is to succeed as a lynchpin of both IT and business transformation. When SOA's virtues are translated to real improvements to real people, we may see the myriad gears of adoption mesh.

There should be a good story here. I think SOA is part of the answer, not the problem. But looking to SOA to change cultures seems to be a moot expectation. Politics changes cultures, and cultures are reflected in politics.

When the business consumers of IT services demand SOA and its effects, then we'll see the real transformation.

Elastra emerges to make cloud computing more attainable for enterprises

Cloud computing as a concept has been gathering significant interest in the past months, but aside from developers, testers and startups, the ability to exploit the efficiencies and cost-benefits of cloud computing for average enterprises have remained hard to grasp.

Startup Elastra unveiled its approach today to making cloud computing more practical, introducing two markup languages -- one (ECML) that helps pull applications together to deploy to a cloud environment, and a second (EDML) to help define and organize the right cloud-based infrastructure to support those applications.

In general the Elastra approach provides onramps to compute clouds based on descriptive tools that help reduce complexity for IT departments. This should encourage experimentation and ultimately lead to ramp ups in the use of public clouds, as well as the build-out and use of home-grown, so-called private clouds. Less attention has been given of late to the promise of private clouds, which are really a natural extension of current datacenter consolidation, clustering, application modernization, ITIL and virtualization initiatives.

As virtualized software has become the primary layer over now-buried hardware that architects and engineers must deal with, we should expect more tools and "bridging" technologies like Elastra to emerge to help grease the skids for what can (and should?) be deployed in clouds. The software then becomes agile services that can be provisioned and consumed via innovative and highly efficient business models and use-based metering schemes.

I suppose we can coin this as "middleware for cloud computing," or maybe "APIs for cloud computing." In any event, let's hope these onramps become highly visual, automated and increasing based on widely accepted standards.

Because Elastra's approach allows applications to be deployed to public (like Amazon's EC2/S3) or private clouds (like the ones many enterprises are likely to build out as they virtualize datacenters), it aims to become a de facto standard for accessing cloud resources. Packaged under the Elastra Cloud Server, the database-driven product can help bring applications rapidly to a pay-as-you-use model. Enterprises may be able to provide more applications as services, charging internal consumers as a managed service provider.

I had a chance to sit down last week and discuss the arrival of ECML and EDMl with Kirill Sheynkman, president and CEO of Elastra. He was a major force behind integration and enterprise portal provider Plumtree Software, which was acquired by BEA in 2005. Indeed, there are a lot of former BEA folks under the hood at Elastra.

Sheynkman is obviously a fan of cloud-based infrastructures, and also has had experience on what it takes to practically define and introduce a new category to the enterprise IT mind. His vision for the cloud opportunity is compelling, but his feet seem firmly on the ground, with a strong sense of what will work in real-world use.

Part of Elastra's DNA is putting more data in the cloud, where it can be used assiduously to support apps, services and business processes. And once the data layer makes its way to the cloud (private, public or both), can the rest of the support infrastructure be far behind? We're already seeing a lot of talk around integration as a service, and infrastructure as a service. And we're also increasingly seeing tools and development as a service.

Once the IT support infrastructure is effectively abstracted to a cloud, with specific languages to manage and access those resources, then the move to Nick Carr's utility vision seems well under way. What remains is for the tools and architecture definitions to be readily described, communicated, and managed for the compelling economics of cloud-based support to take off.

I'm beginning to think the segue to the cloud could happen sooner than many think, and be very much a mainsteam enterprise endeavor after all.