Telling Stories: Mashups in Action

Here at JackBe we’re always trying to move the state of the mashup art forward. In past posts we’ve described mashup best practices like the 5Cs of Enterprise Mashups, mashup security, the integration of mashups with important enterprise solutions technologies like your SOA, and products like Oracle and HP Systinet.

Last week, while listening to one of my customers enthusiastically describe his enterprise mashup, it occurred to me that we’ve neglected one of the simplest and most useful ways to move the state of the art forward: telling the mashup story. That is why we’re starting a regular blog topic we’re calling ‘Mashups in Action’. Here we’ll share any real-world story that shows the value of enterprise mashups. So here’s my inaugural entry...

I recently visited with a CIO at a major medical research facility. He described the complex processes his researchers did every day. Along the way he described how they manually pick research data and citations from public sources like PubMed (and other third-party biology/genome data sources) and manually matched this against an internal datasource of research results through some key like topic, date, publication, or author. Then he dropped the bombshell: this matching process could take anywhere from days to weeks, occasionally even months!

Of course doing this in a non-mashup-enabled way would take exceedingly long. But the issues don’t stop there. It’s also error-prone, tends to age quickly (the final dataset can be out-of-date as soon as the first cut-and-paste is done), and most important to the CIO I spoke with, it is incredibly insecure (emailing spreadsheets? c’mon!). And that’s why this is my first Mashup in Action.

This Mashup in Action serves as a good metaphor for a number of JackBe's customers. It is about connecting the ‘outside’ to the ‘inside’ and it is one of the premier usage patterns in the areas that are research-heavy like legal, medical, intelligence, and investment.

I’m sure you’ll quickly realize that knowledge workers everywhere do this all day long, day after day, into spreadsheets or something similar. They start in common outside-the-firewall sources like SaaS apps like Salesforce.com, websites like Google, publicly accessible data services like Xignite, or an inside-the-firewall app like SAP or Oracle. These users select a small subset of data from these very verbose data providers as the starting point for their analysis because that’s all they need to get the job done.

Next, they use the some kind of unique identifiers in these data set(s) to join the data to an internal source. The internal sources are ones you probably know well, including off-the-shelf apps like SAP/Oracle, homegrown client-server application, or even other mega spreadsheets. The result is a composite data view used for decision making.

In a mashup this can be done in minutes to hours, of course. And they get the added benefits of security and collaboration, allowing researchers to save, tag and share resulting mashups for use by peers without exposing the data insecurely in an emailed spreadsheet or HTML page. Even with the issues of distance and security, it can be done better than days, weeks or months through enterprise mashups.

We’ll be back in a few weeks with another Mashup in Action. And, as always, we’d love to hear your stories!

Read More...

Summary only...

The Semantic Enterprise: Are Semantics the Future of Mashups?

Is it just me or does it seem like semantics are trying to compete with mashups for the ‘it’ technology crown of 2008? Tim Berners-Lee reiterated his vision of the Semantic Web. In case you haven’t heard him do this pitch before, here’s the jist of it straight from the interview:

‘In the semantic web, it's like every piece of data is given a longitude and latitude on a map, and anyone can 'mash' them together and use them for different things.’

And perhaps not coincidentally, there was a note in TechCrunch around the same time about Yahoo’s foray into semantics: ‘Yahoo talked about their plans to allow third parties to alter and enhance search results with structured data that may be useful to users’. These comments really stood out in my mashup-centric mind. This all sounds very similar to the everyday definition of a mashup!

Semantics and mashups have the same goal of connect-the-data-dots but have very different ways of going about this complex task. And its in the devilsh details that I have seen enterprise technologists find semantics more problematic than Berners-Lee or the folks at Yahoo. Why? Because ‘Semantic Web’ isn’t the same as ‘Semantic Enterprise’. And there's the trap.

I have been enthralled by semantics since the now-distant point in my career where I was responsible for a semantic information integration product. I even had an ex-DARPA PhD on contract to try and help me wrap my head around the not-too-simple subject. And based my experiences I must say that even I can see a myriad of potholes on the road to the Semantic Enterprise. So forgive me if I appear to be putting my foot on the semantic brakes but the pragmatic voice in the back of my head just won’t be quiet. I hate to sound like such a hater on such a great concept. I just have concerns.

First, there's the conceptual underpinnings of semantics itself. It is a complicated topic to say the least. In my old role as semantic pitch-man I used to joke that I could turn off even the most technical audience by using terms and phrases like ‘semantics’ ‘ontology’, and ‘equivalence’. Few understood these tenets and even fewer had any hands-on experience with them. (Perhaps Yahoo’s efforts will begin to change this.)

Of course, even if the fundamental concepts were understood by your every-day enterprise technologist, there’s the state of the semantic technology to consider. In a lab, it is simply amazing to see the power and value of a semantic network. I am sure the folks at Yahoo would agree. In practice, however, it is simply amazing to see how hard they are to create, how complicated they can be to maintain, and how sluggish generally slow they can be in production. I heard one industry pundit remark recently that his efforts at creating semantic ontologies universally led to shouting matches and no unusable results.

Final, there's the practical differences between public, SaaS-type of world Yahoo lives in and the behind-the-firewall world of the enterprise. Practically speaking, there aren’t many Yahoo-caliber solutions available for use inside the enterprise. The best (only?) is perhaps Oracle with its early-stage semantic technologies, with a few niche vendors sprinkled in (like the list of exhibitors at the Semantic Technology Conference.) And while I expect some of these vendors might disagree, it is near impossible to find enterprise-grade semantic solutions that show scale, show adaptability and don’t require a PhD to maintain. They all still have that ‘only for the extreme early adopter’ feel.

Last, I think (actually, I know) one of the biggest potholes on the road to the Semantic Enterprise will be the enterprises themselves. Bringing semantics to the Web, a set of reasonably similar collections of knowledge that are 10-years-old at most, can be imagined through a combination of machines and community efforts (albeit a community the size of Yahoo’s). But inside the typical enterprise you have 35+ years of information and information technologies to get ‘semanticized’ and, SOA efforts not withstanding, it is siloed, often undocumented, and about as disparate in format as you could possibly imagine. And unlike Yahoo, you don’t have armies of semantic-tagging volunteers.

Sure, these issues will be worked through. But it will be a while. In a past post I asked ‘…what does an organization's [information-hungry users] do while it’s waiting for [it’s] SOA effort to reach critical mass...?’. I think the same question applies here. So here’s an attempt at a positive conclusion: Mashups can be the gap-filler between today and the Semantic Enterprise. The results can be just as powerful and, more importantly, mashups are something your enterprise could begin today. Once semantics get their enterprise-kinks worked out, they'll make a valuable source of information for enterprise mashers.

Are semantics the future of information? Of course they are. But when will they fit the world of the enterprise? 2 years? 5? 10? More? Well, that’s the real question, isn’t it? I suggest you mash while you wait.

Read More...

Summary only...

Enterprise Mashup Security 101

Gartner published a report recently on Web 2.0 security, ‘Security Features Should Be Built Into Web 2.0 Applications’, a follow-up to their November 2006 ‘Web 2.0 Needs Security 101'. Excerpting straight from the more recent report: ‘The distributed and dynamic nature of Web 2.0 complicates security protection for enterprises and individuals.’ Understated, to say the least.

So this got me thinking on the unsexy-but-critical topic of mashup security. We have posted in the past about ‘Confidence’ and ‘Governance’, but these have generally been non-specific. So let me try to get a bit practical. The question isn’t a simple one but it is certainly worth noodling: How do we execute mashups safely in the context of the enterprise?

I think we are all aware of the security landscape today. On the technology level alone, security is a messy word of old and new systems that do or do not have any connection to corporate monitoring, authentication, authorization, and logging solutions. And it gets even more complicated once you add the ever-changing set of mandated and self-imposed privacy and data control policies and regulations. You can begin to understand why Enterprise Security Architects don’t get much sleep.

Mashups must play nicely in this complicated security ecosystem. For the sake of this discussion, let’s use this working definition of a mashup: ‘an enterprise mashup is a user-driven micro-integration of internal and external data’. From this definition, we can extract the following important security meta-requirements:

1. Mashups are often created by ‘end-users’ themselves;
2. Mashups can be shared with others who may be outside the firewall;
3. Mashups can be created from disparate sources which may be outside the firewall;
4. Mashups can be created from disparate sources which may be of disparate interface formats (RSS, REST, WSDL, and SQL Databases, most likely).

Generally, meeting these meta-requirements can get very complicated very quickly. But it can’t be done as an afterthought! You must be proactive and persistent. Based on these meta-requirements, I’d propose the following Enterprise Mashup Security Guidelines.

1. Entitle and Propagate. Your enterprise mashup must manage the user authentication inherently, delegate the credentials the appropriate identity management system and all mashed-up services. Your enterprise mashup solution must also allow the mashup creator to specify desired entitlements. And all of this must be treated uniformly and seamlessly when mashing up internal and external services.
2. Standardized but Agile. Your enterprise mashup must propagate credentials in the format the source services require. And this security/credential propagation must be built into the architecture because standards are weak here. Of the four service types, only JDBC/ODBC compliant databases and WSDL (via WS-SecurityPolicy) have a somewhat ‘standard’ credentials format, albeit ill-adopted. Therefore, your enterprise mashups must have the flexibility to pass user credentials in whatever form the service providers require, perhaps leaving a placeholder for new standards or custom formats.
3. Portable and Syndicatable. Mashups and mashlets provide the portability for mashups to be syndicated. Imagine your mashlet embedded in a Web 1.0 portal such as BEA and Oracle Portal or in a Web 2.0 interface such as Netvibes, Pageflakes, or your iPhone, that mashup widget must maintain portable security and governance no matter where it goes.

Enterprise Mashups have the potential to be the technology equivalent of the Wild West. Follow the Guidelines and you’ve got yourself a sheriff. Ignore the Guidelines and you could get yourself some quality time in the pokey.

Read More...

Summary only...

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...