abstraction – nettech Blog

December 8, 2017July 8, 2019

Factory Approach to Service Engineering – Preamble

World of Perspectives

We all see the world from different perspectives, and the sum of perspectives help us to get a better/fuller understanding of our world. In this article, we share a perspective on engineering services for business. This perspective can be summarised as: Intelligent Laziness – strategies to achieve equal or better productivity with equal or less effort and minimal stress. To illustrate how we try to achieve this, we will use five metaphors:

Factory
Pattern
Framework
Process
Service

PowerPoint Summary: A Factory Approach to Service Engineering

The Factory – First Glance

When people think of factories, they imagine the primitive/simple product-focussed line that spews out large numbers of identical, low-value items.
http://www.verbolt.co.za/company-home.htm
But there is another perspective; the advanced/composite service-focussed systems that create a few bespoke high-value units to specific customers.
http://www.orangecountychoppers.com/
There are similarities, in that both are repetitive and they both transform inputs to outputs. But there are significant differences too. The primitive factory involves lower risk, and less complexity whilst the advanced factory multiplies risk due to composition and customisation. There is a direct relationship between value and complexity, and it is often the case that the advanced factory uses outputs from primitive factories.

But factories occur in software engineering too, and the underlying principles apply here too. Whereas it is common to talk of dichotomy in software engineering: is it a science or an art? Software factories do not suffer such ambiguity. For every factory, whether hardware or software, two principles always apply:

The outcomes are predictable
The process is repetitive

Careful study of any system reveals re-occurring things/trends the production of which can be achieved with the factory principles. This is equally true in a McDonalds restaurant as in a Rolls-Royce workshop. This is also true in software engineering, especially service engineering.

The Pattern

The re-occuring things/trends in a factory are patterns. The predictability of the output of a factory and the fidelity of repetition depend on patterns. Patterns are fundamental to factories. In a factory, there is a need to understand what is to be produced and the patterns that are involved in its production. Each pattern is a kind of template. Given certain input and application of the template, a given output is guaranteed. A factory is likely to involve mastery of one or more patterns, depending on the type of factory. Fewer patterns generally reflect superior understanding of the problem domain. However, some patterns go through special evolution (exaptation) and could become the focus of a factory in their own right.

The Framework

The collection of patterns required to create a given output can be described as a framework. A good analogy is a box of Lego. It is a composite of patterns, which can be put together to create the structure illustrated on the box/packaging. The framework identifies all requisite patterns for a given output, and usually in a given technical/business context. Each pattern in a framework form synergies and are known to be beneficial in the specified context; examples of frameworks include building regulations (hardware) or Oracle AIA (software).

The Process

Of course having all the pieces of a Lego is insufficient to construct the picture on the box. The process elevates the framework from static to dynamic. The process describes how the patterns in a framework are to be sequenced and aggregated in a way that delivers synergy and the best output. The framework is a snapshot, whereas the process describes a flow from conception to completion. For business services, the process is the first point where IT and business meet. The process shows how value can be created while hiding (abstracting) the taxonomy/ontology of patterns and the framework(s) employed.

How does all of this come together, especially in our daily lives as software engineers serving businesses? And how does this help our clients (the business) better compete? Join me in the next instalment where I will be looking at the benefits, business connection, and potential future impact.

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

December 8, 2017December 8, 2017

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

June 16, 2015January 10, 2017

SOA Services Abstraction

There are many ways to conceptualise SOA services within an enterprise, and there are many ways to organise the implementation units. Here is an illustration of the SOA services architecture of a recent client. I think it is a tidy model, but as in my recent post on governance, “Rhema Bytes: Governance a Rope that Holds Development to Architecture?”, one must bear in mind that a model is only as good as its implementation. Furthermore, every model needs evolution and in the medium term, managing constructive change can be difficult, or disastrous. The devil is in the detail.

What is described here is a high-level view of a canonicalisation context, and it is very similar to Oracle’s AIA. The basic idea is simple. Having disparate clients and partners, a business needs to expose a platform of services, with the minimal set of technologies, components and patterns. The aim is to deliver the fewest generic patterns required to manage the boundary, and the implementation of internal functions. Whatever the design or model, every day use will throw up issues that require consideration. Not everything will fit any model. There will be calls for a dispensation for non-compliance, temporary exemption and technical debt; or changes to the model where inadequacies or incongruences are discovered.

It is useful to reference the post, “Rhema Bytes: The Business to SOA Nexus”, where the discussion was on core services that a business offers, and the automated processes that realise those services. To recap, the post identified business processes as a key focus of IT, and their implementation as the automation of business services. These automated business processes (BP) are the primary targets for the clients of the eBusiness. Most other services will normally be subsumed within the lifecycle of these business processes – with some exceptions. The BP is at the top level of the abstraction model under discussion here.

The diagram below provides an overview, with some AIA mappings:

The genres of service shown in the diagram are described below:
BP – Business Processes (composite, long-running, process-centric, use cases)
Facilitates integration with core services and business, but is never accessed directly
Groupings: Process, Utility
AIA Equivalent: CBP, EBF
GS – Generic Services (composite or atomic, use cases)
Primary path into the enterprise for partners and integrators
This is an intermediation layer that decouples the enterprise from external systems
Types: Atomic, Composite
Groupings: Process, Data, Utility
AIA Equivalent: EBS, EBF
PS – Primitive Services (atomic use cases)
The only route outwards from enterprise
Secondary path into the enterprise – in addition to the GS
Types: Wrapper (BP), Adapter (GS), Mediator (partners), Facade (internal apps)
Groupings: Process, Data, Utility
AIA Equivalent: ABCS

BPs are the typical target for end users, especially human clients. However, there are exceptions, e.g. utility services, where a simple or business-agnostic use case delivers some value. Another example is for system integrators that compose existing services into new mashups. In such scenarios, it would be superfluous to add the overhead of a process. A BP must not be directly accessed by a partner. That would represent an unacceptable level of coupling between the enterprise and partner systems. Instead, BPs are accessed through an intermediary service; the details of that kind will follow in short order.
…
Partners that are involved in the value/supply chain may find it expedient to integrate directly with lower level services. In this case, the generic services (GS). This à la carte access is a complement to the prix fixe integration at the BP layer that is available to B2C and other clients. This option is of particular benefit where there are incongruences between internal order of tasks in equivalent processes.

Generic services (GS) are the default intermediation layer. GSs aggregate lower level services into functional components (data/process/utility), and serve as a facade for all underlying service units. GSs stand between the enterprise and partner systems and also decouple services internally. A GS will provide services to BPs and peer GSs from other groupings. A GS can be atomic or composite, depending on the number of lower level services that are involved in its value chain.

At the lowest level are the primitive services (PS). These are the gateway to the outside world. There is only one way out for requests emanating from the enterprise, and that is through the PS. The PS is the canonicalisation frontier for the enterprise; all, or most, mediation occurs here, be it data, protocol, security, transport, etc. Like the ABCS in AIA, PSs will convert from an application-specific schema to the canonical schema using custom EBM/EBO equivalents. The PS is also similar to the ABCS in that it normally routes requests to other services through the GS above it.

Partner (client) systems do not normally integrate inwards via a PS. Instead requests should are routed to the canonical GS layer. In most cases, this rule is good, but there are exceptions, due to significant differences between the types of PSs:
PSM – the default; this is a general purpose mediator to a partner system
PSF – a facade; this is wrapper around an internally developed application
PSA – an adapter; this facilitates a partner to access a service in a non-standard way
PSW – a wrapper; this simply puts a thin, non-active, decoupling layer over a BP

While the great majority of integration scenarios will be covered by the PSM variant, the other three break the rule. Either because they introduce a secondary PS layer (PS-to-PS) or that they facilitate access to the enterprise directly – (PS-to-BP), (PS-to-App).

The model is similar to Oracle’s AIA, but there are a few differences. Incoming requests go through a generic interface, rather than an application-specific interface, as this cuts down the number of services – see exceptions above. Also, a request to a BP only goes through canonicalisation in a PS before it is directly passed on to the BP. Another difference is in the schema design; this model uses lightweight, flatter EBOs and very strict EBMs that constrain data domains. The end result though is the same, although each approach has its strengths and weaknesses.

These service genres have clear functions which are not elaborated here, and there are preferred technologies for realising each one. The characteristics of the interface of each genre and the interaction patterns between genres are also largely predetermined.

In another article, “Rhema Bytes: A Factory Approach to Service Engineering”, the velocity and efficiency gains of automation is examined. This model is useful as a basis for creating templates or a factory for concrete building blocks. Each template is preconfigured with defaults for all the functional aspects of its type/class, and can be easily configured by developers to fit specific use cases. This has great value, especially for dispersed teams; it gets the horse to the river, quickly and easily. Of course the next challenge is to get it to drink 🙂 But that is a tale for another day!

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