A few words on – The Cloudera Model

Mike Olson, the Chief Strategy Officer at Cloudera, eloquently articulated the philosophy behind their business model in this LinkedIn article titled The Cloudera Model. I highly recommend anyone working on open source platforms and building value on top to stop coding, and read this article. Like right now!

I would like to highlight one quote from the article:

You can no longer win with a closed-source platform, and you can’t build a successful stand-alone company purely on open source

Finally somebody said it!

For years, I have been convinced of this model. I have often wondered how pure open source companies actually make money and justify such large valuations without offering any kind of monetization other than offering training, support and development services on top of the open source projects. Some do it via dual-licensing model, as Mike points out in his example of how SleepyCat worked it before getting acquired by Oracle.

Now, I don’t know if this is the best model that Mike has articulated, but it is close to Winston Churchill’s idea of democracy where he said something along the lines of:

…it has been said that democracy is the worst form of government except all those other forms that have been tried from time to time.

I feel the similarly about the Mike’s call, and I believe this is the best model of all the models out there currently to think of how you want to build a company and balance between open source and closed source to create unique value on top of open source. For most part, it seems that people agree with Mike’s article (based on LinkedIn comments and tweets). Those that don’t agree are in denial.

Use, contribute back, innovate (both open and closed) and create value – that sounds like a good viable business model.

JackBe Engineering Methodology

Often I have been asked by customers, partners and friends, what methodology we use at JackBe to deliver our product releases. The closest I have come to describe it is to brush it off by saying we use Agile development methodology. But that is just scratching the surface. When you dig me in for more specifics, I end up scratching my head to explain coherently. So I thought I would share my thoughts briefly to see if I can catch the main message I want to convey about this topic. For a brief comparison of the various approaches under the agile umbrella, see what Martin Fowler has already said about that subject.

At JackBe, the methodology we adopted was crafted out of several approaches and stabilized over time. The number one goal was to keep delivering the releases and features, and not let processes get in the way. And we did that successfully over the past 7 years, averaging 3-4 releases per year, which I believe is a significant and consistent achievement in enterprise software products business. Let me discuss around the 2 most popular methodologies and my take on how they were relevant to our approach:

• On XP The values espoused by the XP approach (Communication, Feedback, Simplicity, Courage, and Respect) were fundamentally intrinsic to our team, and that took a lot of time and effort for us to cultivate initially. However, once this was in place, as new members go on the team, they quickly absorbed and contributed to the approach and became an integral part of the team very quickly. However, though we initially started with a bit of Test Driven Development (TDD), but over time it became hard to maintain that in our development cycle. This often meant, that tests took the back seat to other aspects of development, but we were only accumulating the technical debt, as testing the software later racked up the bill. The number of unit tests we were writing as a team dropped drastically as the rush to push out new features became a business priority, and this is one of the traps that most development teams fall into.
• On Scrum While Scrum recommends a periodic sprint (say monthly) that the entire team coalesces around delivering, we sometimes adopted this principle. However, we did not follow the daily scrum meetings and there was no Scrum Master to do this. Instead, we valued open and continuous communication between all the members of the team including myself so that no task would get held up in order to reach the goal of delivering a software milestone. Our team did not wait for daily scrum meetings, we just took up the issue as it arose and resolved it. We did have the weekly team meeting as it was necessary to get everyone aligned and re-aligned to ensure we were making continuous progress. But the main work of communicating and aligning was done daily on a continuous basis allow the weekly meetings to provide a wider update and status check for the team. Many others in the industry who use the Scrum approach rigidly, have complained that the team finds the daily scrum meetings which should be taking very little time, turn into hours of debates. If you have a good scrum master, perhaps this can be avoided, and it also depends on the overall personality of the team and individuals in the team. See http://www.scrumguides.org/

So in my experience, there is no one single methodology that one can simply adopt for the entire team. I believe it is the collective responsibility of the engineering leader and the team to craft the team’s own agile methodology by choosing the various best practices that are best suitable for the team, the product and the business. Each methodology comes with its own framework, values, practices and constraints. They are meant to provide guidance in determining your own successful course, and there is no need to be rigid about what you want to box yourself in. Make your own agile methodology by choosing the best of breed, blending with your own and team’s experience and skill set.

At any cost, do not forget the original purpose of your work, which is delivering high-quality software, and become a slave to the process. After all, delivering software is our business and we must enslave the process to do our bidding!

Next Generation of SOA is Here: Are You Taking Advantage?

[Cross posted from my JackBe blog]

Since blogging my 2013 BI predictions, I’ve come across ZapThink’s predictions and one of them caught my eye. No, it is not about Big Data. It’s about something that has gone out of fashion, almost. It was about SOA. Here is the excerpt from ZapThink:

Next generation SOA begins to coalesce – For years, ZapThink has touted the difference between the practice of SOA and purported implementations of SOA. Our mantra has always been that SOA is protocol and technology independent: it doesn’t require Web Services, or ESBs, or any of the heavyweight IT infrastructure that has given SOA its reputation of complexity and failure. With the rise of Cloud Computing, architects are increasingly realizing that the bits and pieces of SOA best practice – loose coupling, intermediary-based abstraction, and automated governance, to name a few – can and should be applied as appropriate, independent of the existence of any specific, funded SOA effort.               

Back when we started building our Presto platform at JackBe—seems long ago now—our goal was to actually build the bridge between all the services and data sources in an enterprise with the business users who really need to access it. Over time, we built our flagship Enterprise Mashup Server to fulfill this need and introduce this slice into the enterprise architecture as a meaningful way of extracting ROI from your SOA investments and delivering real value to end users and business users. Now, we do that and more.

For example, we’re delivering comprehensive insight into the full spectrum of operations for critical decision-making and for measuring the business impact of every occurrence. And we’re doing it all in real-time. We don’t advocate complex architectures or re-architecting your existing systems in the name of SOA. Why would you if there is a better way? We like to work with what already exists, leverage and complement them to bring the value of these otherwise inaccessible systems and data sources.

I like to think that we liberate these silos of information, bring them together in a quick, nimble and rapid way that we are known for, and generate new business value out of thin air. By correlating existing data sources and combining new and old information sources, we are able to mash them up to generate new insights in real-time for our customers. This now proven approach is already here and is what we have always believed as the continuation of the SOA marches toward the users. Such an approach already embraces the concepts of loose coupling, intermediary-based abstraction, and so forth, and yes also works with stringent security mechanisms already in place in your enterprise architecture.

So, the next generation of SOA is already here, you don’t need to wait for 2014 to take advantage of it. Are you ready to exploit it?

Big Data Gets a Real-Time Face-Lift

[Cross posted from my JackBe blog]

Read through any technology publication, website or blog and I dare you to tell me you didn’t come across a Big Data story. Big Data is hyped. And that’s not the first time I’ve said that. In fact, the last time I addressed this topic I declared that one of the biggest problem with Big Data is the disconnect between how much it’s talked about and how much it’s understood. Cindi Howson of BI Scorecard recently hit the nail on the head by drawing an integral connection between Big Data and BI. She dared to say—against advice from a fellow Strata Conference attendee that it might be considered blasphemy—that Big Data is more than Hadoop. She couldn’t be more right.

And Gartner’s Hype Cycle for Emerging Technologies 2012 prominently featured Big Data and linked it to various other emerging technologies, with Big Data just entering the “peak of inflated expectations” and predicts it will take 3-5 years to reach the “plateau of productivity.” But don’t just walk away. Big Data as much as it is hyped, is also real and it is here to stay and is making new inroads every day.

My colleague Dan Malks recently shared some of his 2013 BI predictions and now I would like to follow it up with a few of my own. Yes, I’m focusing on Big Data. But it also turns out—in a great minds think alike kind of way—that real-time intelligence will be a critical element to navigate the way in which we consume, analyze and leverage data of all types and from all places, for instant decision-making. Here goes…

• Big Data will go more real-time, for real. Forget about batch processing. Data that is stashed away without the ability to understand it on a continuous real-time basis is just another old data warehouse, albeit a Big Data warehouse.
• Business users will want direct access to insights derived from Big Data, again in real-time, and anywhere. Here I am talking about the kind of tooling and processes needed to make it easy for the business decision makers to have insights delivered to them in real-time from analyzing Big Data warehouses— especially on smartphones and tablets.
• Big Data will get further segmented into Big Data, Big Small Data, Fast Big Data, and Fast Small Data, along the dimensions of speed/velocity, size and volume. The capabilities (technical and non-technical) needed to handle these are different for different segments.

That’s my two cents. What do you think will happen next year? Share your predictions with us in the comments section or on Twitter using the hashtag #BIin2013 for consideration in an upcoming post.

Using enterprise mashups to save billions

I just came across this from Joe McKendrick on ZDNet Blogs that caught my eye – Study: Increase data usability, save billions.

Here is an excerpt:

Researchers say data usability can be improved by focusing on the following factors:

• Intelligence of data “can be improved through the accuracy of the prediction, trends analysis, recommendations and profile matching/associations made by the associated applications. For example, what percentage of recommendations made by a business intelligence application results in cross-selling?”
• Remote access to data and applications is essential in an increasingly mobile workforce.
• Sales mobility “involves the ability of salespersons to use portable devices and applications to exchange information related to all aspects of a deal or transaction with a customer.”
• Improvements in data quality will result in improvements that “may come through better and timely decisions (which may increase customer satisfaction, loyalty and hence revenues), as well as fewer errors and rework, lower working capital requirements, faster receivables, etc. (which will lower costs).”

A 10 percent improvement can add up to big dollars. Researchers determined that if a median Fortune 1000 business (36,000 employees and $388,000 in sales per employee) increased the usability of its data by just 10 percent, it would translate to an increase in $2.01 billion in total revenue every year, or $55,900 in additional sales per employee annually. — End of excerpt

I find this is very interesting. But, the question is how do you go about achieving this.

1. You don’t want to be spending millions to save millions.
2. You don’t want to take years to achieve this goals.

If you can afford to do either, then I suggest, you read no further.

To me, enterprise mashups have been at this for a few years. Take remote access to data and applications for instance. It is dead easy for us to create a new enterprise mashup that wraps the existing data and applications, creates a specific usable view of that data, and then expose this mashup as a Web Service (SOAP or REST), using Apps to your end users and customers. This does not take years, it can be done in hours and days today.

Consider mobility. You want to not only create a more usable view of data, but in turn ensure that this data is available for your mobile users to interact with wherever they are via any portable device. This too is fairly easy to achieve using enterprise mashups.

Basically, enterprise mashups create that agility layer in your enterprise architecture to deliver concise, specific, usable data and applications to your users, without disrupting your current enterprise architecture. This new agility layer can respond rapidly to new business needs by changing the enterprise mashups and creating new enterprise mashups when required.

Enterprise mashups don’t solve the traditional problem of data cleansing in the traditional way…Extract/Transform/Load (ETL). That’s the whole point. Most customers can’t afford (time or resources) cleansing data that way. I think that enterprise mashups thrive when conventional solutions become expensive and time consuming.

How do you define an ‘Enterprise App Store’?

[Cross-posted from my JackBe blog.]

Lately everyone here at JackBe have been very focused on the latest edition of Presto and all it’s cool App and App Store features. We’ve hosted lots of webcasts, given tons of demos, briefed a lot of the media. And while I admit a certain bias, I think Presto 3.0 with its emphasis on user-driven Enterprise Apps and a user-centric Enterprise App Store has been well received.

But Apoorv Durga, the Portal and Web Content Analyst at CMS Watch, recently wrote ‘JackBe’s App Store is interesting but not new‘. He’s not wrong, exactly, but I think he’s missed the point. He emphasizes that ‘App Stores’ can deliver great ‘time to market’ through reusability and ease-of-use (I agree!) but then quickly condemns most past/present products on these qualities. And that’s where I think Presto 3.0 really is different.

In my last post I talked about how Presto 3.0 provides all the necessary tools and infrastructure to create Enterprise Apps and Mashups. We made every step of the ‘Enterprise App Lifecyle’ easier, from the beginning (secure registration of Mashable information sources), to the middle (easy and secure creation of Mashups), to the end (creation of Enterprise Apps from your Mashups/Mashables. And what I promised at the end of that post was more gory detail on what happens AFTER the Apps are made. In other words, the Enterprise App Store.

I’ve decided to define an Enterprise App Store for you by example. Where do Apps go after they are made? How do users use them? How do user shares them? I’d like to give you a guided tour of the Presto 3.0 Enterprise App Store and ultimately I hope you’ll agree that the Presto App Store is like the Portal ‘App Stores’ (in Apoorv’s article) as much as my car is like my kid’s bicycle: similar in intent, fundamentally different in design and implementation.

Submitting Apps: Apps get into the Presto 3.0 Enterprise App Store very simply. Apps are created by power users or developers and then submitted to the App Store Manager for publishing to the Store. Anyone who has permissions to create an App can submit it, but only the App Store Manager (there can be 1 or more persons in this role) is authorized to allow an App into the App Store.

This is a very important step in the App lifecycle, I believe. As one banking enterprise architect put it, the Store Manager ‘keeps your App Store clean and safe’. Your enterprise can set the guidelines and standards that App creators and submitters must follow to successfully publish an App to your enterprise App Store. If the App Store Manager decides an App is not ready, for whatever reason, they can send the App back to the creator with comments for further development or modification. Once these issues have been successfully addressed, App creators can resubmit their Apps for consideration to be published to the App Store.

Using Apps: What can you do with Apps in the App Store? Once you find an interesting App, if you have the right permissions, you can instantly use it. You can work with any number of Apps simultaneously at any time. Every App you open is shown in the ‘Open Apps’ gallery, and we maintain the state of all open Apps so that you can multitask and switch back and forth between Apps without losing your data. Once you are done using an App, you can close it.

Making Apps Personal: If you like an App and anticipate using it frequently, you can add it to the ‘My Apps’ gallery in the App Store. My Apps lets you add your own twist to the App: customize the App with you own settings (login information, colors, search parameters, etc.) for your very own personalized App. A single App can become dozens of customized Apps for region, data ranges, subjects or whatever parameter(s) you want to personalize.

Sharing Apps: What about sharing? You can easily share an App with other users in the App Store. You can also share with others outside the App Store via email or instant messaging. You can also rate, tag and send comments to the App creator.

Embedding Apps in other sites: You can put your App in other webpages. You get the embed code for an App and stick it into your iGoogle page or your Wiki or web page or even your portal server. You can also publish Apps from the App Store to your Microsoft SharePoint instance as native Web Parts. The point is, you can deliver the App to where the users work and need it – in their wiki, portal, web page, SharePoint, etc. on their desktop, mobile phones, iPads, etc.

Making the Apps secure: All the Apps published in the App Store are secured by authentication and authorization policies configured in Presto by your security expert. Every App can be configured to provide universal access or, if configured, to require the user to authenticate themselves. This can help provide Apps with contextual data or capabilities, if needed. Furthermore, all the data sources consumed by the Apps are protected via Presto security for authentication and authorization. Sharing is secure as well, rest assured. Even if you share an App with me, unless I have the correct permissions, I won’t be allowed to actually use the App.

So, do I think this is a typical App Store? Not in the slightest. The Apps aren’t made, shared, or used by IT with the business people in mind. The business people are the makers, the sharers, and the users. This empowering model is one I’ve rarely seen formalized in the way Presto does. And that’s the part I think Apoorv missed in his post. I am sure that once he gets his hands on Presto, he will surely come to notice all these differences that make our App Store a whole lot different than just a portal server or a gadget server trying to be an App Store.

However, I do agree with Apoorv that, by adopting an Enterprise App Store, you enhance your organization’s time to market. What’s different here is that you can harness and unleash the power of your end users with domain knowledge and let them solve their business needs with self-made or self-discovered Enterprise Apps. And your Enterprise App Store can be the last mile to get the data and new functionality to your users when they need it, where they need it, and how they need it!

Mashups: New and Agile way to Integrate

I came across this interesting post: How Mashups Could Eliminate Integration Projects by Loraine Lawson. In a related post, she refers to John Crupi’s article Enterprise Mashups Part I: Bringing SOA to the People which I would recommend to readers who want to understand JackBe’s take on defining mashups. Anyway, Loraine’s post led me to Ron Schmelzer’s ZapFlash.

Here are some excerpts of Ron’s article that caught my eye, with my take on it:

A year or two ago, assuming that a mashup was a web browser-based, static, user interface composition of web-based functionality would be a reasonable presumption. But in the enterprise context, none of those assumptions necessarily hold – we might want non-Web access to mashed applications, we might want to change them regularly, and we might want to mash up information that exists below the user interface abstraction. For sure, Web mashups might embody the ideals of the original mashup concept, but we now have the desire to mash up a wide variety of IT resources from application to infrastructure to data that might be exposed with a wide range of interfaces – or without. And, it’s the desire to mash up information freed from the application that diversifies the mashup term to include the concept of the data mashup.

Introducing the Mashup Tier

My take: This hits the point right on what we at JackBe have been saying all along about mashups. While some mashups are done purely in the UI/Browser, in the enterprise, such mashups need to be supported by a new tier, the mashup tier, which sits between the presentation and business tier. So enterprise mashups will have some mashing done in the client, but most of the mashing happens in server side where security, governance, policies can be applied before any mashing can happen in the client.

Another excerpt:

There are many scenarios for composing data, but some are better suited for static, tightly-coupled, IT-driven, non-Service Oriented form. In fact, 80% of the value that businesses derive from data come from the 20% of fixed, highly optimized data integration approaches implemented over decades. In this realm, traditional data integration approaches retain high value. However, it’s the other 80% of data integration requirements, most of which come from the need to meet short-term, often ad hoc, integration requests that cause 80% of the problems. Anyone who has lived long enough in the enterprise IT space knows that business-driven requests for reporting, forecasting, analysis, or other interpretations of data can present significant complications and cost to the IT organization. The reason for this is that the IT organization is set up to meet the recurring needs of the business and not “situational” needs for information.

Long Tail of Enterprise Software Demand

My take: This highlights another issue which we have been talking about at JackBe about the long tail & enterprise applications need which was so nicely discussed here by Dion Hinchcliffe.

Bottom line: Something new and interesting is happening in the enterprise architecture space. A new flexible and agile tier is being introduced in the architecture to meet the increasing demand on IT and  add value to existing architecture, applications, services and data. Question is, are you embracing this inevitable change? If not, it’s still not too late. 🙂