IT – nettech Blog

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. 🙏🏿👍🏿

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