Get off your fat apps!

I saw a report written by the UPI recently that described a program, the Future Combat System (FCS), that will have more lines of code than Windows XP. Here's an excerpt: “The number of lines of software code required by the project has more than doubled in only the past five years. The Army originally reckoned it needed 33.7 million lines of code. Now it reckons it needs 63.8 million. The paper also cited Dennis Muilenberg, Boeing's project manager on the FCS, as maintaining that the original estimate was 55 million lines of software, not 33 million.”

As far as I could tell this was something the project team was proud of. And here’s the part made me laugh out loud: they originally predicted 33.7 million lines of code but in fact will likely end up with 55+ million lines of code. They were only off by 20 million lines of code. How could anyone possibly think to spin this as a good thing?

Certainly the natural tendency is for software developers to add more. As an ex-coder myself I must admit that it’s harder to write less code to solve a problem. If you take a senior developer and a new developer and give them the same problem, the senior developer will write less code most of the time. But more importantly he/she will tend towards creating reusable frameworks and modules for an optimally layered solution. Without layers you get spaghetti. With layers you get something more like lasagna. And in this case it’s lasagna that can make you “thin”.

SOA can be a great start to a nicely layered lasagna-like solution. SOAs efforts can greatly promote reusable, accessible business functionality. But it isn’t a slam dunk. We now know the most successful SOA deployments are those that expose ‘business-granular’ services. You know that you’ve hit the business-granular mark when you can describe the service and the data it exchanges in business terms. Can you say this service processes a Purchase Order and notifies Suppliers when Items are delivered?

Unfortunately, once we’ve gotten the SOA part right, we're falling back on old habits by building big apps right on top of our nicely layered, business-granular services! Some of us are even creating these big apps using fancy new RIA (Rich Internet Apps) tools like Silverlight, Flex or Ajax. But these are still fat apps!

But it doesn’t have to be this way. JackBe has begun delivering to its customers something we call a ‘mashlet’, an enterprise-grade mashup widget that can be shared with others or even embedded in portals. They are easy to create (particularly compared to apps that have 55+ million lines of code!) and make a nice dynamic topping on your elegantly layered services lasagna.

I predict the near future will not be fat. The future of apps is much, much thinner. Do you have enterprise widgets in your architecture strategy yet?

Read More...

Summary only...

Implementing SOA without Enterprise Mashups? You might as well kiss your job goodbye.

Ok, ok, its an overstatement. But the ROI of SOA is difficult, at best, to define and measure. Have you noticed that the press and blogosphere is filled with SOA implementers/analysts discussing the ROI of SOA and the idea that stand-alone SOA efforts are DOA? For a small snapshot of this teacup tempest, look no further than the recent commentary from SOA expert David Linthicum, the Nucleus Report on SOA ROI, and the subsequent commentary from ZDNet's Joe McKendrick and IT advisors Neil Macehiter and Neil Ward-Dutton.

While these experts differ on issues like the importance of SOA ROI, how to calculate SOA ROI (if at all), and why we don't have more/better of it, they all seem to agree on one thing: 'Enterprise-wide support for SOA hinges on the ability to demonstrate value to the business at large — more growth, revenue opportunities, and all that good stuff.' (Joe's words, not mine.) And that's where your job is at stake. Or, at least, the long-term support of your SOA efforts.

Let's face it, SOA is plumbing. Nice, shiny, efficient plumbing to be sure, but still plumbing. And your average business dude/dudette (think sales manager, marketing director, finance officer, or customer support rep) could care less about it. In fact, if they think about it all, they probably just hope it stays right where it is: out of sight and running quietly. These same business folk probably appreciate the marble floors, wood-paneled doors, and brass fixtures that surround this plumbing much more. In other words, they like that bit of 'stuff' that actually frames the plumbing and brings it to life.

SOAs need to change this inward-focused quality. To paraphrase Macehiter/Ward-Dutton in their recent note, 'More big vs small thinking: SOA vs BPM', IT must focus on where the real business value of SOA lies. That means it needs help. Macehiter/Ward-Dutton point out that BPM can help distill some SOA value up to the business level. And as one of the early implementers of Enterprise Ajax, JackBe knows from extensive first-hand experience that Ajax makes a great service consumer.

To this collection of SOA-complimenting tools I'd add the enterprise mashup. JackBe has found in its enterprise mashup implementations that they can actually drag the SOA out of the proverbial IT basement and onto the end-user's desks. It's not only highly visible, but it's user-driven, giving IT a way fulfill the promise of SOA and enhance that elusive SOA ROI.

As a practical guy I like definitive examples. Luckily, we've already seen a number of very real synergies from the mashup/SOA combination. Just a few of them include:

• Mashups can help create normalized 'virtual' services from sources that haven't been 'SOAed' yet. It's no secret that SOA efforts can take years. Until the formal SOA magic has been applied, a quick, standardized service can help users get started earlier than otherwise.
• Mashups let users 'right-size' the granularity of services. Now IT doesn't have to guess/study/analyze whether a service offers data that is 'too specific', 'too general', 'too dated', or 'too cold'.
• Mashups let users share their resulting services, making them a part of the service-generating network. Now IT doesn't have to do it alone.
• Mashups let end-users visualize the SOA in graphs, charts, tables, maps, etc. Instead of hoping the aging corporate portal has a place/way to get services visualized in the way(s) the users want , users can each do it themselves to meet their own ever-changing needs.
• Mashups let users join in data from outside the enterprise. Today's SOA efforts are largely inwardly-focused. But users often want to include external data in their work. Mashups don't care and good mashup software makes the actual location of a data service irrelevant.

SOA is still relatively new. Enterprise Mashups are, urguably, even newer. So you are likely just getting your Enterprise Mashup mojo going. But if SOA is on your enterprise to-do list, make sure you get Enterprise Mashups on that plan as well. It may not cost you your job, but it could move your SOA from 'questionable' to 'successful'.

---

Parting Comment 1: Kudos to Geek and Poke for distilling this talk of SOA ROI down to a single cartoon.

Parting Comment 2: Coincidentally, JackBe's blog has talked in the recent past about the cost-of-ownership for enterprise mashups. We didn't do a survey or try to define formulas. But our multi-part blog on 'Enterprise Mashups and Total Cost of Ownership' (here's part 1 and part 2) is a good look at some of the business and IT impacts involved in enterprise mashups. (That's a biased opinion, I admit.)

Read More...

Summary only...

The Age of Customization: Enterprise Web 2.0 is the perfect pair of pants!

I spent last weekend searching for pants. I had a need. I looked for pants that were comfortable in the winter and summer but would always ‘breath’, the right material so they would last, and also pants that would be acceptable for multiple occasions. The problem is I couldn’t find a pair that met all these needs. I had to buy multiple pairs. I settled on the only solution that was available at that time. I will have to adapt the right solution (many pants) instead of having one solution (one pair of pants) that adjusts to my needs, when I need something different as situations arise.

I want a pair of pants that could change on-the-fly (no pun intended) easily; adapting to the environment and occasion as I see fit.

Well, we might not be able to do this with pants but now we can with Enterprise Applications. In fact, this type of flexibility, customization and efficiency of a solution that adapts to multiple needs will be the standard in five years time. Three forces are aligning to make this happen.

• Web 2.0 – user empowerment and customization
• Ajax – technology techniques to bring richness and back-end interactions to the user
• Services – Exposed through SOA or other, services are the enterprise applications building block of tomorrow.

These forces are aligned to support the next generation of Enterprise Applications that will be common place in 5 years. These applications will be browser-based. They will unlock the value of information previously contained in separate silos through granular services. With AJAX client side technology, they will consume these assets and allow users to interact in a rich and dynamic fashion. And with the 2.0 social networking and collaboration aspect, the tilting of the IT pendulum back towards the client side leads to more empowered end users capable of generating content and even their own ad-hoc, mashup applications.

Now you can customize your organizations applications to your needs instead of forcing your employees to adjust to a heavyweight, monolithic solution that might not be a right fit for their need. Even further, you can empower your employees to further tailor the solution to meet a particular situational need when they need to.

Why will these applications be the standard?

This new paradigm is difficult for some to grasp. We have been offered large solutions that we had to make fit into our organization and make work for what we had to get done in our jobs. But the productivity that these applications brought to transactional activities is drying up. The future is focused on the knowledge worker who has tacit activities to accomplish and where no solution has arguably truly demonstrated much benefit with regards to optimizing these people’s situational activities.

This is where organizations can increase productivity. The problem is that because of economy of scale past applications couldn’t be developed to meet these situational, micro activities needs. The technologies weren’t all there, understood enough, or further, understood in the context of their synergistic relationships which yield the capabilities to meet these knowledge workers activities needs.

The Enterprise Web 2.0 Application can. It can because the forces listed above are now converging. Enterprise Web 2.0 is a natural evolution of consumer facing Web 2.0 Applications. Web 2.0 has introduced public consumer users to its benefits and now enterprises have begun to catch on to the technologies and techniques to further their web-based applications; to leverage existing assets, whether it be data locked behind a firewall or intellectual knowledge locked in your employees heads.

I can’t wait to see what unfolds this year! (pun intended)

Read More...

Summary only...