mashup
Enterprise Mashups – The Icing on your SOA
The Dilemma
I have been spending a lot of time recently learning about enterprise mashups. The new startup that I am working for is building a SaaS solution that will be consumed by various types of customers and partners. These customers and partners may want to consume our data services as a RSS feed, gadget, SMS message, web page, within a portal or portlet, or a number of different ways. I do not want to spend the rest of my life developing new output mediums for our services. Instead, I would rather spend my time adding new business services to enhance our product and service offerings hence contributing to the bottom line.
Enterprise Mashups to the rescue
Enterprise mashups will allow me to offer my partners and customers the ultimate flexibility to access our products and services in ways that are convenient for them without having to wait on my IT shop to decide if (a) we think the request is important enough in our priority list, (b) if we have the time and resources to work on it, and (c) how much we will charge them. On the IT side of the house, with an enterprise mashup strategy in place we can be assured that whatever mashups our customers and partners create, they will be subject to the same security and governance as the services we have developed. The diagram below shows a logical view of how our SOA will be designed.
As you can see, we have clearly abstracted the various layers within the architecture and they all inherit our overall security policies. SOA governance is applied to this architectural approach to enforce our standards and design principles. Overall IT governance provides oversight over the entire enterprise which includes legacy systems (we don’t have any legacy yet), third party software, etc.
Now let’s add the enterprise mashup layer. We want to hide the complexity of our architecture from the end user and expose data services to them to consume. At the same time we want these mashups to be equally secure as the services we write and adhere to the same governing principles. Enterprise mashup products provide tools to make managing this layer easy and efficient. The diagram below shows the enterprise mashup layer inserted into the architecture as a layer on top of SOA.
 |
| From SOA Slides |
Enterprise Mashups in simple terms
If the concept of Enterprise Mashups is still not clear, check out this white board discussion with JackBe’s CTO John Crupi.
I spent some time talking to JackBe’s VP of Engineering Deepak Alur a few week’s back. Deepak discussed how enterprises have been focusing more on infrastructure and technology and not on the consumers of data. As he coined it, many shops are “developing horizontally and not addressing the needs of the users”. He talked about how users were doing their own brute force mashups by cutting and pasting data from various places into Excel. This creates various issues within the enterprise due to lack of data integrity, security, and governance. It is ironic how corporations spend huge amounts of money on accounting software and ERP systems, yet they still run the business out of user created Excel spreadsheets! The concept of enterprise mashups addresses this by shifting the focus back to the user consumption of data. Here are some of the requirements for mashups that Deepak pointed out to me:
- User driven & user focused
- Both visual & non-visual
- Client & server side (although most are server)
- Plug-n-Play
- Dynamic, Adhoc, Situational
- Secure & Governed
- Sharable & Customizable
- Near zero cost to the consumer
Jackbe’s enterprise mashup tool is called Presto. Presto is an Enterprise Mashup Platform that allows consumers to create “mashlets” or virtual services. IT’s role is to provide the security and governance for each data service that will be exposed for consumer use.
Presto Wires is a user friendly tool to allow users to create their own mashups by joining, filtering, and merging various data services (as shown in the picture below).
In this example the user is combing multiple data points from many different organizations in an automated fashion. They could then present this data to multiple different user interfaces and devices. All without waiting on IT.
Here is a simple example of a mashup of Google Maps with a Carpool data service.
The folks who create the Carpool data service where able to leverage the Google Maps service without having to write their own mapping software and without having to know the underlying architecture behind Google Maps.
How this solves my Dilemma
Back to my dilemma. By leveraging a tool like Jackbe’s Presto or WSO2’s Mashup Server, I can now present various data services in a secured and governed fashion to my customers and partners without being concerned on how they want to consume it. Whether they want the mashup on their own intranet, as a desktop gadget, as an application on Facebook, or what ever they dream of, all I need to be concerned with is the SLA of my data services. This also makes my product offering more competitive than my competitors who have proprietary user interfaces that do not provide the flexibility and customization that the customers desire. As I said in the title, this is the Icing on your SOA cake. For those organizations who are disciplined enough to implement SOA and follow the best practices of design and governance, the reward can be an simple addition of an Enterprise Mashup Platform on top of your SOA stack. This is the ultimate flexibility and agility that SOA promises.
Mashups and SOA wars
First it was WOA vs. SOA, now it’s Mashups vs. SOA. When will people start focusing on business problems and stop having religious wars about which technology is best? All of the above mentioned technologies are great tools for your IT toolbox. They should be used where they make sense. SOA is an architectural approach. Mashups and WOA are technologies that work well with SOA. Why can’t we all get along?
One of the items on our SOA roadmap is extending our architecture to include mashups. We envision leveraging popular mashups like Google maps but we also hope that our customers can extend our products and services with their own mashups. Take a look at all of the mashups that are available for Salesforce.com.
I’ve said it before and I’ll keep on saying it until somebody proves me wrong. The problem with these emerging technologies is not the technologies themselves, it is the people. Only people can take great concepts like SOA and Mashups and create a bunch of unnecessary noise that scares the masses away. Instead of arguing about semantics, people should try to better understand these concepts and figure out how they can apply them to solve real business problems. At the end of the day, the business doesn’t care what technologies you use. They just want their tools delivered faster, easier to use, and at their finger tips wherever they are.
Selling Web 2.0 by doing Web 2.0
One of the challenges for selling Web 2.0 within the enterprise is explaining the value that it brings. To many long timers within IT, Web 2.0 technology is a play thing that the younger generation uses at home. Many can’t comprehend the enormous potential that WEB 2.0 can bring to the table in the form of collective intelligence, social networking, RSS feeds, APIs, and folksonomies. You can show graphs and charts, talk about the intangibles and the tangibles, and power point them to death all day long but the best way to sell Web 2.0 is to do Web 2.0.
Here is an example. I am trying to sell the concepts of enterprise blogs, wikis, and RSS feeds. When I discuss these with many of folks within IT I get way more laughs then I get head nodding. When I sit down with various groups within IT and even within the business to explain SOA, I go directly to some of my blog posts and to specific wiki pages to show visual images to help explain the concepts. Look below for an example (single click for quick slide show, double click to walk through slides with captions).
Just today I was working with our SQA team to explain some of the differences in testing SOA applications versus the traditional client server applications that they are familiar with. I bounced around my blog to find a few posts that helped explain what an ESB is and what the layered approach to distributed computing (SOA) looks like. Tonight I took some of the images off those posts and created the slide show above with Google’s Picasa. This is a great example of showing the power of Web 2.0. I put together another album from a presentation I did the other day that discussed leveraging some Web 2.0 tools to improve internal communication.
It you are selling the concept of mashups internally, take one of your internal applications that has a customer database and do a proof of concept that calls the google maps api and displays your customer on a map. This will easily allow you to explain the concepts of mashups to anyone within the organization. Here is an example of looking up ITToolbox.Com headquarters using Google Maps.
Imagine if you could do this with your CRM application when your sales guy hovers over the customer name! Show the business what Salesforce.com is doing with mashups.
So in the words of fellow blogger James McGovern, don’t just give presentations about technology, have conversations. By showing people what the technology can do instead of talking about graphs, numbers, and case studies, you can start a constructive conversation to explore the possibilities. Through conversation, people can bring ideas to the table that you never envisioned. Give it a try and feel free to use this blog post to prove your point. Remember, don’t just talk about technology, do technology!
Built to change, Architected to last
I wrote an article several months ago named Built to last is a thing of the past. Yesterday, at BEA World in San Francisco, a speaker mentioned the phrase…
Built to change, architected to last
I think that this is a great motto and one that teams starting SOA implementations should use as a their vision. Built to change, architected to last is all about agility and flexibility. BEA is touting their own new acronym called Dynamic Business Applications. This new term refers to an architectural mindset based on four principles:
- Built to change (flexible)
- Embody business processes
- adaptive
- agile
This mindset is BEA’s response to today’s business environment where the business is changing faster then IT can keep up with. The solution is to provide a platform of business processes and services which allow users to design and/or assemble their own composite applications (mashups). The days of buying enterprise third party applications and forcing the users to use the canned processes and features are over. The business changes so fast that third party packages become a crutch over time due to their long release cycles. Simply put, the packages can’t keep up with business needs. The answer is take the best of breed features and services from the combination of third party packages, SaaS solutions, and custom code and present a common interface that integrates all of the functionality together into a single view of the users’ workflow.
Dynamic Business Applications is a shift to a world where applications are human made and designed for the way people work. The IT team delivers business processes, business services, core infrastructure, and integration services. The business can then create their own composite application by assembling all of the pieces together. Think of it as the Lego approach. The IT team builds the rectangles, squares, wheels, and various connectors in all different shapes, sizes, and colors. If the users want to make a boat, the choose all the pieces necessary to make the boat. If they want to make a plane, they choose the pieces necessary to make a plane. The users did not have to wait for IT to build them a boat or plane.
To accomplish this, IT must work closely with the business to identify the core business processes and services. This is where it is extremely helpful to establish a SOA roadmap. Once you have identified the collection of business processes and services in some key area of the business, you can then prioritize your deliverables by delivering the processes and services with the highest chance of reuse first. This greatly improves your speed to market in the long run.
Another shift in thinking that should be mandated in organizations is to move away from creating reports and move to creating information. My philosophy on this topic goes like this….
You should only develop reports if it is an output of the system (ie. bill, invoice, purchase order, etc.). Otherwise, IT should leverage business intelligence and deliver data as content to the users with a tool that allows them to format the output and drill down into the data as needed.
Why do we continue to pay developers to write custom reports only to get frequent change requests to change or add new columns, create multiple output formats to please different individuals’ preferences, and make changes to group or sort things differently? Not only is this expensive and an inefficient use of people’s time, but the users typically have to wait for IT to make these changes. Although these changes may be quick to make, it may be a long time before the change is high enough on the priority list to get worked on. Wouldn’t it be better to present data to the users and give them self service capabilities to define their own reports, create their own dashboards, and do their own what-if analysis?
IT needs to become an enabler instead of a bottleneck. We should stop building custom applications and start building the building blocks that can be assembled into Dynamic Business Applications.
What does it all mean?
So many exciting changes are happening in the world of IT today. Look at all the hot topics from around the net that we read about each day:
- Virtualization
- Web 2.0
- SOA
- BPM
- Saas
- Outsourcing
- Open Source
- Mobile Computing
- Event Driven Architectures
- Mashups
- Collective Intelligence
- Super fast chip technology
What does this all mean to the future of IT? Most of these technologies (if done right) will impact the workplace in a variety of ways. Some of these technologies will enable people to be fully functional from remote locations (Mobile Computing, Web 2.0, Mashups, Collective Intelligence). Some of these technologies will eliminate human processes both in the business (BPM, SOA, Event Driven Architectures) and IT (Virtualization, Outsourcing, SaaS). Others will make us less dependent on the big vendors (Open Source, Virtualization). Then there are the advancements in chip technology and memory which can really rock our world. Can you say diskless PCs?
So as I read article after article, day after day, I begin to wonder what this all means to the working people in IT. I can be pessimistic about the future of IT and paint a picture that looks like this:
- Mass virtualization - elimination of many systems administration and networking jobs
- Mass Outsourcing – Most of development farmed out due to cost effectiveness of remote development (both onshore and offshore)
- Less internal development – Reduction of development jobs due to effective end user tools (BPM, Mashups, Web 2.0), external development (Outsourcing, SaaS), and improved collaboration and automation (Collective Intelligence, Event Driven Architectures, SOA)
Or I could take an optimistic view of the future of IT:
- Business Alignment - business heavily relies on IT for automating and streamlining business processes (BPM, SOA, Event Driven Architectures)
- Enterprise architecture – Architecture becomes key differentiator and enabler
- Rapid development, less maintenance – Tools (Mashups, Web 2.0) and architecture provide a platform to rapidly deploy. IT delivers loosely couple services, not proprietary monolithic applications, which reduces maintenance and allows for more new development.
- Cost effective computing – Business looks to IT as a partner and an enabler instead of a cost center. IT makes the business efficient (Mobile Computing, fast chip technology, collective intelligence) while being cost effective (SaaS, Virtualization, Out Sourcing, Open Source, BPM, etc.).
My belief is that it will come down to the IT leadership, mainly the CIO. The CIO needs to measure and promote the value of the IT department as we move through these dramatic changes in technology over the next few years. He or she must be a trusted business partner to the CEO, CFO, and COO. IT should be proactive and start implementing these technologies (where it makes sense) to enable the business, as opposed to waiting for the business to tell IT to implement these technologies to reduce costs and headcount.
So what is your view of the future of IT? Is it pessimistic or optimistic? If it is pessimistic, what are you doing to change it?
