Factory Approach to Service Engineering – Business

From Technology to Business

In a previous article, I looked at how some metaphors can be used to understand the engineering of software (services).  Of the five listed below, I introduced the first four.

• Factory
• Pattern
• Framework
• Process
• Service

The first three have a clear technical focus; the fourth is a gateway between the technical world and the business world.  The fifth though is where the business focus becomes paramount.

IT is an enabler – no one invests in technology for itself, rather it is for what IT can do for business.  The service is the business perspective on the process.  It focusses on how all those patterns and frameworks abstracted within those processes can be put to work for business. But even business is not without patterns!  Every business operates in a sector, and belongs to a genre.  For every business genre, there are certain must-have competencies common to all participants, as well as some differentiators that are peculiar to some players.  The build up from our patterns to the processes must be honed to effectively serve out clients; the business, who themselves have clients: the buck-paying end-users.

 

The Service as Business Nexus

The reliability, efficiency and quality of our technical processes must feed into our business clients and aid their agility.  A business that is supported by factories at different levels (pattern, framework, process) is more able to adapt to a changing environment.  Such businesses are able to recombine solutions at different levels of granularity to address emerging needs.
It is vital to make a distinction between software-engineering per se and service-engineering.  At the different levels of the vertical hierarchy of software, there are factories that have no alignment to any business whatsoever.  They are simply technology enablers.  The focus here is on services, i.e. software that is “client” driven.  In a Service Oriented Architecture (SOA) there is an intrinsic/instinctive alignment to business.  I go even further to speak of a “fundamentalist SOA“, characterised by the following principles:

• Build Best
• Owner-Agnostic
• Interdependent Services
• Service Ontology
• Attritional Evolution

We should build on Steven Covey’s (The 7 habits of highly effective people) principle of interdependence and Steven Johnson’s (Where good ideas come from) ideas of next-adjacent, serendipity and exaptation.  Everyone should not build everything.  No one should build just for themselves.  But let every output be seen as a target (service) for the genre or sector/industry rather than the department or the company.

There are significant benefits to this mindset:

• Cheaper solutions: due to successful scaling of a few best patterns
• Easier, Faster: due to extreme specialisation of the most successful patterns
• Simpler Maintenance: due to deep understanding of the pathology of the patterns
• Fewer Faults, Quicker Fixes: due to clear modularity/decomposition of the patterns
• Better Scalability: due to to built-in fundamental qualities of patterns
• More/Better Output: as patterns are re-composed at higher levels of abstraction

But these kind of solutions are themselves products of a new learning.  This learning is focussed on the core nature of the problem rather than its specifics.  It is meta-learning that looks for patterns in the problem domain and then maps each to a resolver in the solution domain.  This Weltanschauung delivers, and it is an enabler for federation of output as seen in open-source software.  It is a value well demonstrated in Amazon Web Services.  Without this mindset, corporations like YouTube or DropBox would not have gotten off the ground.  With it, the evolution of novice to expert is more likely to be successful and the duration of the transform is more predictable and much shorter.  One expects that all this would also produce more of Jeff Bezos “work-life harmony” for those involved.  As well as better and cheaper output for those buck-paying clients, at all levels!

Plus ça change … ?

Computers know nothing! Deep-blue would not know how to crawl out of a pond if it fell into one. But we can teach it to.  We communicate with machines through patterns; the patterns represent an abstraction of our language and knowledge.  The patterns help us to teach machines, and thereupon to delegate to them.  Better abstraction means we can get more out of the machines. The patterns are our bridge to the nebulous machine world.

Increasing the variety and the speed at which we add abstractions will hasten the metamorphosis of ideas to reality.  Each one extends our metaphorical bridge; from the machine end to the human end.  As we do so, alterations to our present reality will emerge ever faster, as our most abstract ideas and desires are projected across bridge of abstraction into new and tangible experiences.  The foundation of all this is and will be unavoidably linked to those principles that we started with earlier: the factory, pattern, framework, process, and service.
That is my (view point) perspective.

Good day and God bless.

—
Oyewole, Olanrewaju J (Mr.)
Internet Technologies Ltd.
lanre@net-technologies.com
www.net-technologies.com
Mobile: +44 793 920 3120