Everyone Wants a Platform

author-photo
Latest Articles

Definition of Platform – Computer Science:  The basic technology of a computer system’s hardware and software that defines how a computer is operated and determines what other kinds of software can be used.

Coming on board at Stuzo I realized that we deliver great custom social engagements that can scale and are delivered with repeatable patterns and process. We have built common web services and technology allowing us to build those engagements. Our social technology platform determines what other kind of software can be used, right?  Why not call ourselves  a platform company; everyone else is doing it.

Why does everyone want to label themselves a pure platform?

Every product manager and owner stretches to find a way to call themselves a platform, but why are they seeking this label?  In the definition we find something very alluring, “determines what other kinds of software can be used”. If you can be the platform which “determines what other kinds of software can be used” then you rule the world. Hard to blame anyone for wanting that label.

Even more alluring enterprise customers want platforms. Enterprise customers are a smart group and have learned that platforms give them power as well.

In economic terms we have demand and supply. So the demand side has to work hard to define what they want and validate what they are hearing. While the supply side listens to the market, builds their platform, and then hopefully sends a clear message to the market.

Why don’t we call ourselves a platform company?

Business DNA. At Stuzo our culture is defined by fanatical delivery for our customers.  Doing our best to getting it right and doing right by the customer. When coming on board at Stuzo you don’t have to be told this; it is set everyday by example.

This does not preclude us from calling ourselves a platform company, matter of fact we are our proud of our social technology platform. It allows us to help organizations standardize across their business. We have for ourselves and help others build repeatable practices for social technology. With the type and amount of applications we have built and the integrations applied we can claim flexibility.

We are also privileged to work in between agencies and brands.  Sometimes using the full flexibility of our social technology and other times being adoptive of customers preferences. Our drive is in creating social applications on the Internet of things, this is fun for us. And we have a platform more diverse than anyone in the social technology space allowing three architectures – Compact, Distributed, Cloud. Like any good platform, here is a box diagram:

We are a social technology company first with a deployment proven platform. Our services architecture allows us to use best of breed services where customers require specific implementations or where partners provide functionality outside our core expertise.

How are we becoming a better platform company?

By going open of course. In our architecture we have three layers

Application: The framework for building applications. Our application development has been PHP and we have recently updated our application architecture to be a pure API model. Pure API model allows our applications to be integrated with native mobile applications ( if we build them or not ). Our web and mobile web front end architecture is build using Angular, however, everything on the back end is an API – Angular is our choice.

Internally we have standard applications, which act as a base for different categories of applications.

Services = API, implementation  Admin UI: We have a set of core services that are required by most social applications. These services are things we do not need to continually rebuild and range from publishing to analytics. An application can choose to use the compact form of analytics deploying within the application or leverage the shared analytics installation.

Admin = Admin UI, DevOps API: Our Admin infrastructure is also a set of APIs with an overall Admin UI using those APIs. In making our deployment options flexible and admiring all things AWS we think of our DevOps capability as an API of our own, though under the covers it cleanly wraps Capistrano and AWS.

The process of going open will happen over time, our first task is to make public the API end points for all of our services. We will follow on with implementations of some of the services as we map out the important parts of an open platform.

Share this story

Latest Articles

Don't Miss These...

Contact Us

Please let us know if you’re interested in our software services and Open Commerce platform, in scheduling an Insights briefing, or establishing a partnership.