Architecture – nettech Blog

January 23, 2024January 23, 2024

Newsletter – Why Architecture

This is the first newsletter article proper. I will try to keep this brief, but If there is sufficient interest, I could spend some more time/words on the topic. Our topic today, is an important question, and one that architects will face from time to time. Here is a recent article that I wrote on this subject. Do read it if you can, as it covers details that I will not rehash here.

But in answer to the question, my response has always been that the drivers for IT architecture are, mindset and environmental imperatives. The first is proactive, while the second is reactive. As you can expect, I recommend the former (mindset) over the latter, because it instils architecture from the get-go. Such organisations seek excellence, are in for the long haul, or seek to rapidly gain market-share in an existing market. Because of their ambitions, such businesses will prioritise strategy, even in MVPs.

Almost always, this strategic view percolates from champions in the highest levels of the business (c-suites typically), to the IT area. Because the influence is coming from the highest levels, the effects are pervasive and resilient, resulting in an IT culture that is closely aligned with the business aspirations. In this kind of enterprise, what one may label as MVP, is actually an optimal release for the time, constraints and environment of the business. Because it is under-girded by sound business and architectural thinking. This is not true for all organisations, particularly those that employ architecture reactively.

Some other organisations introduce architecture, as a response/reaction to changes in their environment. The stimuli that I identify are, scale, complexity, and risk. Some experts also mention cost, but I think cost is a direct consequence of the three primary imperatives. One is unlikely to see costs going south while any of these are going north. When things get more complex, scope multiplies, or risks (regulatory, financial, legal, others) emerge, most organisations will wake up to the need to engage staff outside of day-to-day operations. Unfortunately, this is often problematic, because governance becomes a big issue.

Folks who previously made their own decisions, now have to discuss it, and perhaps, submit it for oversight by architects. This can create tension, resistance and in some cases conflict, with vassals overseeing strongholds of opposition; overt or covert. Secondly, because architecture has not evolved as a culture, when the immediate need has been addressed, it is easy for those organisations to regress on the discipline of architecture. In the short term, it saves on the stress and tension that the introduction of architecture creates. In the long term, of course, the problems will re-emerge, having evolved into more complex and entrenched threats.

One may ask: what to do, if the architecture function is not yet present in our organisation? My advice is to identify a sponsor that you can communicate with directly. Preferably someone higher up (quite😀) in the organisational hierarchy, and preferably on the business side. Get to know the vision, targets and roadmap of the organisation; from a business perspective. Do your diligence to identify any of the motivations that I mentioned above for mindset-driven IT architecture. Now explain, in simple language, how taking a strategic view that aligns technology change with business change, at every step of the roadmap, will be salutary to success. Continue to state how this can be facilitated by the introduction of architecture.

As one who has led a startup, I can tell you first-hand that most business leaders see tech as an enabler only. Therefore, you must arm yourself with numbers and other quantitative details. Imagine that my goal as CEO is to make 170x in value within a given time, and I have investors expecting 38x of that back in the same time. Your suggestions must show how we can either overshoot the target now, or miss it “mildly”, but secure significant and increasing gains in the near future. If I don’t get that empathy, I am unlikely to consider what you are offering. That is the red, proactive pill.

If that fails, because no one gets the picture, try the blue (reactive) pill as a last resort. Identify existing or potential change imperatives, as I mentioned earlier, and use that to argue for advance preparation. Such pre-emptive action requires a stepping above the business-as-usual (BAU), looking to the horizon and putting plans in place to harness everything in the enterprise, in synergy, to manage anticipated changes. Once again, you will need to demonstrate how the introduction of a strategic (architecture) rather than tactical approach, creates value for the organisation. If you succeed with either pill, be prepared to lead the change. Trust me, it will be challenging, but extremely rewarding, in the short and long terms.

Before I go any further, I need to point out that the focus is not on technical or application architecture, which typically approach solutions from a technology perspective. Rather, it will be on solution and integration architecture. The two roles are very similar, and both work closely with the business, various architecture teams, and the core technical/delivery teams. Henceforth, I will use solution architect or solution architecture as generic terms, for both. I found this video by Marco Lenzo, most enlightening, in illustrating this bridging function provided by solution architects. Marco has several short videos on key technologies, which I find to be handy time-savers.

Solution architecture (SA) has some overlap with enterprise architecture (EA). However, as organisations scale up, the distinction of function is cleaner and the overlap decreases. In my opinion EA, sets the stage for architectural involvement within an organisation (enterprise), whereas SA works with the business and technical teams to deliver changes, within the constraints that EA has previously agreed, and continually evolves, with the business. As you can see from the diagram above, SA has a vital role in keeping the technical/delivery functions aligned with the business.

I initially planned for 500-word articles, but having reviewed the number of topics, and the possibility that more may be introduced, I am doubling that number, to keep the lifetime of the newsletter manageable. Please let me have your comments and feedback for this week. I will respond to any comments, and God willing (GW), continue the discourse in two weeks’ time.

Adios for now. 🙏🏿👍🏿

May 23, 2023May 23, 2023

The Fog of Experience

I still remember the early days when I first started out in tech. All answers were apparent and hardly was the ink dry on the request, and I was already delivering pieces of the solution. It was a kind of “Agile”; quick, and invariably, MVP. The success factors for me were essentially the functional aspects. Value was perceived from a tech perspective.

These days, so many answers are qualified, nuanced, and accompanied by caveats. Almost nothing is clear and certain. I have discovered that value is the prerogative of the customer, and he/she expresses it in subjective terms. However, the customer is often not the only important stakeholder, and one has to address all the concerns of key stakeholders to deliver a successful service. The matrix of concerns, constraints, opportunities, etc. is a hazy mesh that takes patience, knowledge, imagination and tact to navigate.

Oh, for the halcyon rookie days, of operating below the radar of key stakeholders, architectural governance, and budget holders! For certainty and technical purity, for the stream of tactical solutions, and the buzz/hit of seeing “it” work! I still remember one moment of amazement, when a visiting consultant pointed out to me that the collection of MVPs I had laboured over for the last two years was actually a mini ERP. Those were some memorable years, in London, Edinburgh and Southampton. It was a lot of adrenalin, noise, banter, late nights, early mornings, intense work and much fun.

I now work mainly in the integration & solution architect scopes, synthesising services from business, architectural and technical inputs. Constantly scanning for opportunities to drive innovation, efficiency and competitiveness, while also reducing complexity, cost and TTM. In addition to the requisite technical and business knowledge, my role involves tact++, listening++, politics, psychology, emotional intelligence, and social strategy. It is not a straight line, there are no easy answers, there is little fizz, and you do not enjoy a fiat in any context.

Neither do I ever deliver anything alone. I always work with others, no one works for me, but rather with me: hierarchies can oft-times be an impediment. I depend on others to implement, provide or revise funding, change scope, grant a dispensation, review a requirement, move a date, or compromise in one way or another, to advance the delivery of solutions, and value to our customers. Customers are the ones that pay for our activity, and it is key that we understand their perception of value in order to consistently deliver services that they are willing to pay for.

The customer is king! But KYC cannot always be gleaned from the organogram or reading through the requirements. What may be right for one customer with a tight and close market window might be an unacceptable hack for another. The solution that was gladly embraced by customer-A in Q3 of this financial year, when revenue was trending up, could be flatly rejected in Q1 when corrections reveal shortfalls. Over time, one does gain knowledge and one does build trust, and all this widens the scope of influence. However, with such a wide matrix of interdependencies, the role is always challenging and unpredictable.

All said and done, it is still very interesting and rewarding work. It is a journey of discovery, of self and others; of building relationships and trust; of learning from failures and successes; of growing in patience and perception, and of seeing the sometimes hard-to-perceive positive impact of changes one helped to nurture. And “Yes, it is a good life, ‘Henry’“.

August 28, 2015January 10, 2017

Factory Approach to Service Engineering

Rhema Bytes: A Factory Approach to Service Engineering

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

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

August 26, 2014January 10, 2017

Simple Canonical Schema For Maturing SOA

In a previous article (Custom XSD Schema…) I examined the options open to the information architect when deciding on the adoption of XSD schema for SOA service messaging, and whether to choose an industry/community standard or go for a bespoke design that is tailored for the organisation at the point in time.

In this article, I present an overview of a custom messaging model (WSDL and XSD) that should work well for many small to medium sized IS/IT departments (10-200), especially where the information architecture function is either small or non-existent. This model is therefore more than the canonical schema, but the minimal overhead in WSDL is necessary to create an end-to-end view of the service contract that is properly aligned. So, to cut to the chase; let us start with an overview of the message model in the form of a diagram:

MessageModelLayers — Message Model Layers

This message model is like one of those nice layered cakes that you get at birthday parties, each layer has a different flavour and character, and the higher layers sit on, and depend on the lower layers. Similarly, this model is built bottom up; each layer has a purpose and flavour that the layers above it depend/build on.

The Proper Canon: Base, CV and Complex:
At the lowest level, there are base types that constrain required XSD primitives into a few logical and physical domains. The next layer contains the constrained value lists (enumerations), which are all constrained to one of the physical domains in the base types, and from that, define permissible values for certain static values for a generic type.

This layer introduces a peculiarity; “Infrastructure…”. This construct is adopted for one purpose, to distinguish all non-business concepts. In all the subsequent layers, any unit with “Infrastructure” in its name is concerned with IS/IT concepts rather than the core business. Above the constrained values are the complex structures: these are common compound nodes with one or more child nodes/elements. These three layers form our proper canonical schema, in that, everything in these three layers will be used as-is by all services in the enterprise. Above this layer, we encounter a virtual layer, and then a service layer, and in these and other layers, perspective is everything; there is no single view of the world!

The Virtual Domains:
This is the virtual canonical schema. The layer defines the template, or canonical form of all business and non-business (Infrastructure) concepts; the focus of this layer is coverage and correctness of definition and description rather than implementation, and this could be the bridge to an information model at some time. Peculiar to this layer is the absence of constraints on the cardinality of data items; this is deliberate. The absence of cardinality constraints makes it possible to defer this till later when development is imminent and allow all SOA services the liberty to define how the data will be used in their context. The only proviso being that the structure and relationships of the data may not be augmented in any way, i.e. no moving, renaming, adding of nodes or relationships.

The Service Schema:
This layer becomes pertinent when implementation is about to begin; and the focus is in customising data structures from the virtual canon for specific use in the request and response of operations of services that use XML. Much like the CV, Complex, Service, and Virtual layers, the service layer has business and “Infrastructure” units, but both have exactly the same function: to customise data from the virtual canon. The service schema however needs to import the service infrastructure schema, since it is assumed that most services will be business focused rather than IS/IT focused, but the relationship could also be inverted in some scenarios. For example, the data needed for CRUD (Create, Read, Update, Delete) operations will be different, and so it is useful that the interface of the Read operation is not cluttered with data that is only relevant for the Create operation. The service schema could therefore specify only the ID of an Address for the input to the Read operation, whereas the Create will certainly not have an ID, but would need almost everything else: HouseName, HouseNumber, StreetName, PostCode, etc.

Service WSDLs:
The icing is put on the cake by the way of the service WSDLs (abstract and concrete). This layer is included in the model to illustrate patterns that can be used to connect the data for the operations in the XSD to the operation definitions in the WSDL, and to support the premise that automation is not only plausible, but that auto-generation of service interfaces is on the radar. For clarification; the abstract WSDL imports the service schema and is concerned only with the data structures that are needed by a service; the concrete WSDL on the other hand defines the implementation details of the service, i.e. what structures are needed for clients to access the service at runtime.

I hope this first piece has been useful; in the next installment I will build on this by introducing a new layer that will build on this foundation: Namespaces.

Ad Majorem Dei Gloriam.

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