History (in other words you can skip this part :))
When I created publish / subscribe at TIBCO we used to think of putting everything “on the bus.” The “bus” idea referred to a hardware bus. If you know how hardware works information flows between devices in a computer on a set of wires called a “bus.” Along with every piece of information flowing on a bus was a unique combination of 1s and 0s “wires” that addressed the intended “recipient” of the information. All the devices attached to the computers bus have a simple circuit that selects the information that will be received from the bus by that component and reject all information not intended for that device. If different devices wanted they could “subscribe” to everything on the bus by being what was called “promiscuous.”
Why “Get on the Bus?”
Anonymous publish / subscribe
“Getting on the bus” meant that if you integrated your application with the publish/subscribe bus it was automatically integrated with any other application on the bus and the information could be shared easily and anonymously. As an application writer you didn’t have to know what applications might eventually be interested in the information you were sending out and they didn’t have to know who was providing the information. This abstraction meant that publishers and subscribers could be anonymous.
Simplified Communication
It also meant that it took the complexity of dealing with the growing and changing demands on my service and put it in standard components that could be scaled and could handle all the myriad issues that subscribers might want without bothering me. This dramatically simplifies integration and fragility. So was born integration technology. 🙂 Suffice it to say that “getting on the bus” was the way to get everything to work together and to be agile because you could easily reuse services and information if you just knew the “name” of the information or services and you could create a service just by giving it a name and publishing it.
Over the next few years various approaches to “discovery” services, eventually called directory or governance services emerged that enabled you to find what services existed but these were intended primarily as a tool for the techie building inside of an already well known architecture. You could find a service but discovering who else was using it, how it worked, how well it worked was not there. The dream of reusing services really depended on people already having a very intimate understanding of the services. If they already had an understanding then why did they need a directory service? So, even that basic piece of SOA reuse never really took off. A lot of companies implement SOA but don’t implement the registry part.
FAST FORWARD TO 2014 ; “Get in the store”
In my blog The Enterprise Store App, API and Mobile I start to describe the social store that has revolutionized the world of applications and services.
I am making an analogy of the Enterprise Store as an Integration and Management platform for enterprises. You may ask: aren’t there are a lot of Application management tools already? Isn’t it just a nice sexy way to present services and apps for consumers, not a “management” platform? Let me explain why I think this could be the next Enterprise Asset Management platform.
Virtualization of the Enterprise Assets requires a new management platform
The world of CIO enterprise management has changed from being concerned mainly about the hardware and networking “assets” of IT and more concerned with services architecture and applications. In the new cloud mobile devops API bigdata opensource paradigm more and more hardware is virtualized and may not even be part of the mix at all. Instead we are dealing with Enterprise Assets at the Service layer, the Application level, not the router level.
Enterprise Management today is about managing the services and applications not the hardware
Enterprises are seeing the value of many mobile applications and APIs and they see that value primarily in terms of enabling developers and customers to be “connected” to the value chain they create with their Web Apps Mobile Apps and APIs they provide. I am simply speaking of the IT assets in an Enterprise not all the assets. So, since the CIO is now more concerned about this higher level “application and services” they need tools which enable them to manage those assets better at a higher level. CIOs are being asked today to provide services used by outside developers and those developers need documentation and transparency. CIOs are being asked to give usage information not just in terms of hardware utilization and cost but also what are users doing with the services? CIOs are discovering that to properly manage services they need API Management. To properly manage mobile applications they need MAM (mobile application management).
CIO Persona
Most enterprises I talk to tell me that they “know” how their enterprise assets are being used. Usually they have only a few large applications which use any enterprise asset. Everybody knows the applications and services and they know they are monolithic, designed to perform at a certain scale and are watched like a hawk using a plethora of asset management tools.
In the new world of proliferating APIs, mobile Apps and Web apps people may reuse a service in a new mobile application or web app and suddenly there could be millions of hits on that service that didn’t exist before. Possibly the marketing person who thought up the new service didn’t think it would impact the organization. There could be new services developed rapidly or a dependence on an external service that the company didn’t know about or didn’t realize was critical. If you imagine how enterprises might grow the APIs, Web Applications and mobile Apps to hundreds and thousands that utilize these things the state of affairs could quickly become very hard to manage.
Another common problem I see that causes people to look for new technology to manage things is the vexing problem of versioning of services. In the past services changed infrequently, the number of subscribers was few.
The new paradigm for APIs promotes agile development and change. An existing user of a service has to be migrated to the new version of the service potentially very frequently and the number of subscribers is much larger. Doing that without a systematic process that is controlled can lead to lots of gotchas that make the company look like it doesn’t know what it is doing.
Corporations may try and tell all subscribers to switch over to the new version on a single weekend for instance. An almost certain heart stopping moment when everyone holds their breath hoping nothing breaks that causes lots of problems for everyone and sleepless nights.
What if you had a way of knowing all the users of your service, being able to notify them and deal with them automatically, versioning the service and providing old versions of the service for those who can’t do it right away? What if there are 3 versions of a mobile application out there and they use 3 versions of a service? All of these problems are symptomatic of the new paradigm which is the use of open source and public API services, mobile applications and a dynamic agile development environment where people want new services and new applications yesterday and the IT organization has not dealt with this environment before.
If I am a CIO I care about the cost and reliability, security of all these services and where all this is going. How can I do that without understanding everything that is happening with these new uses of my services I provide? I need to have a unified infrastructure that handles APIs, mobile applications and web applications uniformily and as the integrated whole they are. They each affect each other. You can’t manage them independently.
An Enterprise store for a CIO is a place that gives them visibility into the usage, control over the usage, a place to monitor new activity and to plan. It is a place for me to understand relationships of assets and projects to each other and help identify what is costing what, how to reduce costs and what increasing demand will do to cost. The Enterprise store is a powerful management tool for the CIO.
.
CTO Persona
The world of development is moving to a reuse model in which people are reusing services in and outside the enterprise to create more and more applications. Wired (Chris Anderson) and Gartner calls it the long tail of applications. Organizations are refactoring enterprises to provide many new services to either refactor into new products or to offer separately. In any case, the reuse of services is intended to be encouraged and therefore the expectation is that we will see in an innovative company, successful company the proliferation of services, APIs, web apps and mobile applications. Each of these represents a potential trouble spot for the CTO:
1) Security – do we know that all the information these new connected services provide are secure?
2) Performance – do we know that the service will scale to meet demand?
3) Fault Tolerance – do we know these services will respond to failure of any component or how dependent services respond to failure?
If I am a CTO I am mainly concerned with the application and services architecture, i.e. what set of services and data do I have to deliver? How do I deliver those things in a consistent way? How do I use new technology and constantly improve my services? How can I leverage better services faster? How can I insure that I am doing so in a secure way? I am also interested in learning how people are using my services and I may find innovative things to do, new services or faster better cheaper ways of doing things.
I want to understand what people are doing, so I want to leverage bigdata intelligence. I want to get feedback in a social way from various stakeholders. An Enterprise Store with all enterprise assets and the hooks to connect the bigdata feeds of usage across APIs, web and mobile applications, learn about issues and performance, easily create new services and replace old services is a godsend to my ability to foster innovation.
Developer Persona
Do I build from scratch or reuse
As a user or developer of an Enterprise Web App, API or mobile application I am tasked with developing new services and improving them. While I could just create everything myself that would not leverage the value that has been created elsewhere. In some cases I may be smart enough that I really do reinvent things and make them better. When I do that, if people recognize it then that value may be migrated to other parts of the company but in many large companies this doesn’t happen. The cost of someone building custom software is much higher than many enterprises recognize initially.
If there is a place I could go to find the services created by others in my company or “approved services and assets” that I can reuse easily and I could engage with them to improve them to meet my needs or do the improvements myself then promote it we have created an open source approach to software development within one company. I have a blog about this topic which is catching on in many enterprises called Innersource. An Enterprise store gives part of the framework I need to publish my services, advertise them and gain recognition for my work.
I am more likely to reuse other peoples things, improve them than rebuild things from scratch if there is a way for me to easily do that and to gain credit for my accomplishments as well as increase the value of my accomplishment by helping it spread in usage around the company or even outside.
As a developer I want to know what others experiences with the service I am thinking of using are, what other apps use the service? I want to download the apps, test the service in various ways to see how it performs. An Enterprise store is a place for me to see all these assets, interact with them, subscribe, ask questions, post answers and my feedback and results.
Partner Persona
An Enterprise store should have the ability to be used internally and externally. For external users and partners and developers it is a place to learn about my companies services. Companies today want to create a friendly place for potential partners to come in, learn about your services, try them out quickly and build POC’s or even build Apps or modify apps. The social store has proven to be a successful paradigm for this.
The Enterprise Store Vision
An Enterprise Store should be able to handle any kind of Enterprise Asset
There are different types of assets in an enterprise store I am talking about. Some might be web applications, mobile applications, APIs and some could even be source code, shareable libraries, externally approved APIs that can be used within our enterprise, legacy services or almost anything. An Enterprise store should be flexible enough to handle a number of different types of assets.
An Enterprise Store needs to provide transparency
The enterprise store should allow me to express interest in subscribing to the application or service and help me use it. I should be able to give feedback. I should be able to find the status of the applications or services and what others think. I should be able to find a roadmap and who the people to talk to about any enterprise asset. The Enterprise store needs to be secure, reliable, scalable to thousands of assets, replicated, multi-tenant for larger enterprises possibly.
An Enterprise Store needs to be safe
The basic building block of WSO2’s enterprise store is the governance registry. A governance registry is a powerful SOA tool that enabled you to create the “true one known value” for things. A governance registry enables you to create environments and to segregate governance items across a large corporation. It allows you to version entities and decide who can see what and change what entities under what rules.
The governance registry needs to be very sensitive about who can see what items, for instance if you store certificates in the registry. It has to replicate itself among disparate regions reliably and quickly for DR (disaster recovery) purposes. WSO2’s Enterprise Store uses this as the backing store which gives you a scalability and security that is not a toy store (pun intended :)) It also has the social and user interface characteristics to make it fun and easy to navigate, something sorely lacking from governance registries.
One of the most important features is versioning but also the ability to decide what entities someone can see based on role is critical. Some assets are for senior management, some for everyone in the company, some for external parties and many other variations on that may be needed to insure security.
Enterprise Store needs to be Social Tool
People can post things to an entity and it goes to a “wall” into a bigdata store so that you can store virtually anything and any amount of social information with any entity. You need to be able to see who the subscribers of an entity are, the interested parties, owners and you need to be able to communicate with them and rate entities, post your own questions or comments, reviews, tips or problem reports. As a user you want to find advice, pictures of the entity in use, videos, virtually anything about the entity that would help you reuse it or decide if it is the right thing or what needs to be changed to meet your requirements.
Enterprise Store as Management Tool
The next step for the Enterprise Store is to associate management activities with the entities. Right clicking on an entity can bring up a list of possible things to research or do. This could include doing analytics on user usage of the entity, lists of users, interested parties for the entity, dependent items on the entity.
The ES could take you to the real time status of the entities inside, take you to historical status, show you the running instances of the entity and be able to query those instances one at a time or in groups. You should be able to create management dashboards to facilitate managers to grok the state of entities, which ones are the most popular and successful.
From the enterprise store you have a wealth of enterprise value created. No other company has this vision that I am aware of. It is a compelling vision of how enterprises IT could evolve that provides management with the information to better manage the creativity and new services and applications that are encouraged by this platform for innovation and reuse. I call this new corporate enterprise platform API Centric because the center of all the assets is the API. This is how SOA is evolving into something much more important and relevant to all parts of the business than the techie middleware concept that it was conceived as originally.
Summary – Enterprise Store as an Integration Platform
“Putting it in the store” means that you have made something visible and available for reuse and management under a common set of tools and services. This leads to faster integration, more reuse, more innovation and faster time to market.
The Enterprise store can first provide the knowledge of existence which is an important first step in reuse and integration. It then can provide the knowledge to integrate the entity (API, Application, data service) into my application or use case. It can facilitate that by providing you with a subscription to the service. It can even be instrumented to automate the usage of the entity, deploy it automatically or give you the code to paste into your favorite language to use the entity. The enterprise store can also track your usage of the entity. All of these things facilitate deeper and better integration than provided with ESB’s and SOA in the old days.
I heartily recommend you consider an Enterprise Store in your future IT plans.
CloudRamblings 
5 thoughts on “Put it in the Store – The new paradigm of enterprise social asset sharing and reuse: Just put it in the store.”