The Fundamentalist SOA

Rhema-Bytes: The Fundamentalist SOA

Fundamentalism in SOA is to see everything as a service. Raise this thinking to the strategic level and one starts to ask questions of services, such as: “is this a core competence”, and “do we provide it as effectively as others”.

At the technological level, the questions that come to mind are: “do we understand the business requirement correctly”, “have we properly decomposed the requirements into functional units”, and “do we have generic patterns that can be used to implement a solution for each functional unit”.

The end game, in my humble opinion, of this fundamentalist SOA is to have synthesised an abstraction of one’s business context and provided genericised implementations for every functional aspect that is amenable to automation. At this point, IS/IT would have created a platform that delivers the business in a “label” agnostic engine, and this engine could be optimised by trimming off those units that are better/cheaper provided by outsiders.

This SOA enables business by providing a performant platform for delivering services to clients, and the opportunity to outsouce non-core-competencies and inefficient implementations.


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

Rhema Bytes: The Business to SOA Nexus

I have a little confession to make, one of many; it is that I maintain a simplistic view of business. In my simple view, a business starts as an idea or vision, depending on your Weltanschauung, and this idea articulates some value (services or products) that the business will provide to the community – Business (B) or Consumer (C).  It is vital to mention that “service” in this context is an abstraction and has nothing to do with technology.  These services will often require some input, manipulation and output, which will be conducted by humans together with some machinery. The complement of input, manipulation and output, when formalised is sometimes referred to as a standard operating procedure (SOP) or process.

Now for the nexus…
For the business idea/vision to become a reality, there will need to be some transformations in the real world.  These transformations will start from nothing, and incrementally deliver concrete things that advance the business towards the realisation of the vision.  Each transformation is realised by way of projects, and the projects may identify some opportunities for automation of the SOPs/processes mentioned above. Automation of an SOP would be by way of implementation as one or more technological services.

The SOA for me therefore should include a focus on this initial vision and how it filters down through the transformation programmes and/or projects, down to the individual services, as well as the portfolio/complement of all services that serve the business. My simplistic view is that there is a minimum set of core technological services that are needed to support a particular genre of business. That this magic complement can be expressed in a generic form that is not tied to the name/identity of the business that it serves.

To achieve this, the SOA perspective needs to be different: services should be conceptualised with the perspective of an agnostic/outsider. The architect should try to see themselves as a third party providing that service to businesses in general and not to the organisation in particular. This perspective should also be broad enough to identify services that are best factored out, and those that can be profitably re-packaged into a higher value offering.

The end goal being the discovery and clear articulation of the magic complement of services that supports the parent business. However, a delightful side-effect should be the realisation of a platform that can, in part or whole, serve other businesses of the same genre or in the same sector. I am of the opinion, simplistic I agree, that often we are too timid or parochial in our view of solutions. There are not so many unique reference architectures out there, and in the same sector one will encounter so many different implementations even among very similar businesses. I believe we can do better.


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

Factory Approach to Service Engineering

Service Factory

Rhema Bytes: A Factory Approach to Service Engineering

Service Factory
Service factory abstraction

When most people think of a factory, the imagery that is conjured is one of mindless repetition, and the generation of large numbers of low-value items. A good example is a nut & bolt factory. In this world, value accrues to the investors from the little profit made on each one of the millions, or billions, of items.

This does not tell the full story of factories. There is another view that most of us do not readily think of. I call this genre, a compositing factory. Good examples are found in the many custom bike shops found across the USA. Many of who arrange engines from Harley Davidson, and kit from other suppliers, into dream-machines especially tailored for their high-end clients.

Both perspectives have one thing in common. In real life, there are the designers that articulate a general template of the “thing”. And there will be the producers that directly replicate the template, or customise it before replication.  The nut & bolt represents the former (direct-replication), while the custom bike shop illustrates the latter (customised-replication). There are templates and meta-templates for both bike and nut. The nut template will be driven by permutations on materials, size and strength, whereas the bike template is a composition of an engine, frame, gears, tyres and some other bits.

In SOA architecture and design, we are also concerned with templates (ABB and SBB in TOGAF). Our templates are sometimes abstract, sometimes concrete, sometimes composite, sometimes atomic. Whether as a reference architecture, or a component design, the focus is on a template that solves a generic problem. However, most of the time, these templates are not to be replicated verbatim. Their value is almost always realised in some composition or aggregative context. Some intelligence in application being sine qua non.

For any enterprise, there will be a minimal set of services that must be realised for the organisation to be a meaningful participant in its sector. In addition to these core services, there are others that help to differentiate the organisation. These can be regarded as the macro templates. At the micro level, we find that each genre of service must complete certain tasks in order to deliver meaningful value to clients. Once again there could be differentiation by way of order, algorithm or complement, but by and by there will be a minimal set of tasks, that all must do.

If we apply the mindset of the custom bike shop to our architecture practise, we should see quite a few tools in-house that we can use/reuse. Some that can be bought, and a few that we need to fabricate. I have found that while many enterprises adopt the “reuse-buy-build, respectively” principle, not all evaluate the comparative costs of these options before making a decision. The consequence is that build, and buy, usually outnumber reuse in most organisations. In the cases where there is reuse, existing services are rendered functionally ambiguous to cater for slightly different use cases.

In a previous article, “Rhema Bytes: The Business to SOA Nexus”, it was argued that architecture should seek to create a platform of agnostic services that are well suited to serving the genre of an organisation, rather than the organisation specifically. If one were to decompose an enterprise, top-down, it should be somewhat easier to identify functionality at its most granular level. Top-down decomposition helps identify functionality at the highest level of abstraction. The analysis of each granular functional unit can help determine the comparative value of reusing, building or buying services that provide the required competence.

So, for a new business initiative that delivers services X, Y. and Z. We could ask if there is a Harley Davidson engine that fulfills that X, a Volvo axle (Y1), Saab transmission (Y2), and Toyota electrics (Y3) that deliver Y, and if a component Z5a is truly unique, or needs to be built, alongside Z1..Z3, and Z4c that do not already exist in our catalogue.

Each service, whether bought, built, or reused, is then properly catalogued as to the value it provides, its comparative costing, and what contexts it is to be used in. Such a compendium, built over time, makes it much easier to assemble solutions. Every installment of this approach makes the next assembly simpler and quicker. This is because most unique use cases/scenarios are covered off in the early solutions, and subsequent projects will reveal fewer unseen scenarios.

A lasting benefit of this mindset is that federation and outsourcing is made that much easier, since the templates for the product/service or its composition are predetermined. This means that production and assembly can be separated, and the build and testing are more effectively decoupled. In a previous article, “Rhema Bytes: SOA Services Abstraction” one such model for templating service genres in a SOA is explored. Combining this mindset with the pieces identified in that article should result in a flexible, nimble and responsive “service factory”.

Presentation: AFactoryApproachToServiceEngineering.ppt

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

Making the best of your 9-5

Canal Digital office in Fornebu

Work smart, not hard.Canal Digital office in Fornebu

I did a survey of the generation of my dad and his friends recently, and I made an interesting discovery. Most of the “fun” guys are still alive, but the serious and really hard working ones are all gone! I have decided not to end up like the latter group.

The vast majority of human beings spend their best years working. Work occupies most lives between the ages of 20 and 60. Work consumes the best of the waking hours of each day. Work straddles 5 out of 7 days of each week. Every working day, most adults will invest 10 hours attending to their work – about 2 hours commuting and 8 hours on the job.

Every year, we spend more time at work and with our co-workers than at home with our family, or out and about with our friends. Work environments and outcomes have a great impact on the health and life of all but the very rich, and the few contented. Work-related stress often mars the peace at home, but the brevity of the rest and comfort at home greatly limits its impact on work. Perhaps tellingly, a worker is most likely to suffer a heart attack between Sunday night and Monday morning. Wow!

So, make the best of your working life, by choosing to enjoy each working day! It is simple but profound advice; don’t ignore it. Sit comfortably; your butt is in that contraption for many hours each day. Take every opportunity to laugh. I can assure you, it is much better than crying. Laugh at your challenges, laugh at your mistakes, laugh with others as they too stumble through situations. Guess what, most of what seems monumental today, will be irrelevant in a few months, if not a few days. The crisis/catastrophe of today will be next year’s dinner joke. That is a long time waiting to enjoy a joke, especially if you will be the subject.

Don’t scrimp on lunch, you have earned it. Eat well and have a large drink, preferably non-alcoholic; it is lunch, not dinner. Try not to eat alone, you may think there is a shortage of good company and hypocrites crouch at every table. Well, dive in, one more wouldn’t hurt the mix 🙂
Thinking of something nice to nibble? Why not buy enough for a dozen. We all enjoy surprise treats, and niceness is really infectious. You may also be interested to know that it will not alter your financial trajectory. If you are going to be poor, middle-income, or rich, that extra few dollars a week or month will not break the bank. But it will make a big difference to the mood in the office.

Enjoy the environment. Don’t wait until you are in an ideal or dream premises. You may be here for a while, so try to enjoy every day of it. A stroll after eating is healthy, and it just might rein in that runaway waist. If you are up for the challenge, take the stairs rather than the lift. If you keep it up, you may have completed the equivalent of a marathon by the end of each year!

Treat your colleagues well. The opposite is like crapping in the village stream. Everyone gets sick eventually. No one likes being treated badly, and most will find a way to get even. However long it takes. Show consideration and compassion to those who struggle. It is really nice to be nice! You will feel good for it, and the beneficiaries will not forget it/you in a hurry. Payback may not come straightaway, but you will have increased the likelihood of experiencing same empathy sometime in the future.

When away from work try to shut down and enjoy life. Spend quality time with your family and friends, remember you came to work so you can maintain your family and keep up with your friends. No one goes to work to find family or to reach friends. If you drop dead tomorrow, your family will be devastated, your friends will be distraught, and your employer will find a replacement. Get your perspective right. If you were to wake up sick tomorrow, make sure that you can take consolation in a truly enjoyable yesterday.

If you don’t like your job, its time to change. Trust me, it is not worth it. Don’t be conned into “living” in the office. Work-life balance is vital. You just about make that on a 9-5, but certainly not on a 9-9. Don’t over-exaggerate your importance or the value of the task at hand, remember, this is a marathon, not a sprint. Retirement these days is granted in the latter 60s, so if you are still in your 20s to 50s, remember, you may have decades yet ahead of you. Take it easy.

Spend a few minutes reading, viewing or listening to things that delight you. Preferably things unrelated to your office work. You will feel reinvigorated after the break, and new ideas may emerge to hitherto intractable problems. Remember to get up and walk once every hour or so. It is good for your legs, bottom, and eyes. You should save yourself for retirement. You will need those arms and legs if you are to enjoy the fruit of your decades of labour.

Work smart, not hard.

I have acted to change my perspective; to work smart, not hard, and I hope to be around to enjoy a retirement. I pray you will be there too!
Have a great day, work wise!
God bless.


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

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:
SOA Zones with 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).

SOA Services Abstraction Sequence Diagram - Requester

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.

SOA Services Abstraction Sequence Diagram - Provider

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