Architecting application architecture #apparch (inspired by #microservices)

Base references

A few interesting recent discussions about microservices:

• “Gartner about Microservices – is this a Big Mistake after WebServices?” https://www.linkedin.com/pulse/gartner-microservices-big-after-michael
•  “Application Architecture for Digital Business” http://my.gartner.com/portal/server.pt?open=512&objID=202&mode=2&PageID=5553&ref=webinar-rss&resId=2866521&srcId=1-3134301641
• “Microservices vs SOA - Is there any real difference?” https://genehughson.wordpress.com/2014/12/17/microservices-vs-soa-is-there-any-real-difference/
• “µCon 2014: The Microservices Conference” https://skillsmatter.com/conferences/6312-mucon
• “Can I Haz Name?” http://203.softover.com/2014/12/01/ultra-srevices-and-declaration-of-independence/

have inspired me to write this blogpost in addition to the several recent blogposts:

1. “#BPM for software architects - from monolith applications to explicit and executable #coordination of #microservices architecture” http://improving-bpm-systems.blogspot.ch/2014/08/bpm-for-software-architects-from.html
2. “#BPM for the #digital age – Shifting architecture focus from the thing to how the things change together” http://improving-bpm-systems.blogspot.ch/2014/08/bpm-for-digital-age-shifting.html
3. “e-government reference model #GeGF2014 #egov #entarch #bpm #soa” http://improving-bpm-systems.blogspot.ch/2014/10/e-government-reference-model-gegf2014.html 
4. “#BPM for #SOA+#ESB+#API and #cloud (#PaaS and #SaaS)” http://improving-bpm-systems.blogspot.ch/2014/12/bpm-for-soaesbapi-and-cloud-paas-and.html 
5. "Ideas for #BPMshift – Delenda est “vendor-centric #BPM” – How to modernise a legacy ERP" http://improving-bpm-systems.blogspot.ch/2014/04/ideas-for-bpmshift-delenda-est-vendor_27.html

And other references:

• http://martinfowler.com/articles/microservices.html
• http://www.tigerteam.dk/blog/
• http://www.brunton-spall.co.uk/post/2014/05/21/what-is-a-microservice-and-why-does-it-matter/ 

Disclaimer

In this blogpost I try to stay at the conception level and avoid any implementation details (such as WS, REST, XML, API, HTTP, JSON, Web, common libraries, Java, etc.) – let us validate the concept first and then talk about implementation techniques.

At the same time, it is considered that there is no commonly-agreed definition of “microservice”. One of the reference definition of “service” is in http://www.infoq.com/articles/updated-soa-principles .

My definition of “service” is “explicitly-defined and operationally-independent unit of functionality”.

Application architecture current challenge

If, for a moment, we are not fussy with the terminology then we can accept a current challenge in the application development as it is defined by Jean-Jacques Dubray (as a comment to the first reference): the microservice architectural style ...is an approach to developing a single application as a suite of small services.

In other words, the question is how to implement an application as an organised collection of many autonomous components. Each Autonomous Component (AC) is (potentially) distributed (in-house or in-cloud) and thus it is a unit of deployment (otherwise it can be deployed in a separate host).

Note: At present, it is not possible to claim that ACs are microservices or services.

I think that this is a natural step in the evolution of the application architecture.

From monolith: one unit of deployment, one “in-process” (in techie’s meaning – in the same JVM), simple inter-component communication (again “in-process”) and simple error-handling (again thanks to “in-process”).

Then moved to client-server with two units of deployment (but not yet autonomous components): fat client (presentation and some biz logic) and the rest.

Then to three-tier with three almost ACs: thin client (presentation, better UX), business logic (calculations) and data access layer.

Now, with the recent popularity of mobile equipment, in addition to IT-centric decomposition (presentation, logic, data) into ACs, there is an opportunity for functional decomposition into ACs. So, each AC may have its own UI/presentation, logic, data and additional access channels, e.g. classic API. An example of functional decomposition is a portal – a data-centric portal for navigation over some data or a function-centric portal or a combination of them.

Meaning of “autonomous”

The word “autonomous”, being a keyword, requires an extra explanation. Some people associate it with “...Independent Scalability, Independent Lifecycle and Independent Data” but, let us look at the full life-cycle of AC.

In general, such a detailed life-cycle has the following phases:

• Contextualise (or define future AC’s usage/expenses - WHY)
• Plan (or schedule AC’s design, build and run - WHEN)
• Design (or define AC’s characteristics - WHAT)
• Build (or implement AC -HOW)
• Bind (or linking)
• Deploy (WHERE)
• Run
• Monitor (or meter of the usage of AC - WHO)
• Measure (or evaluate the performance of AC – WITH WHAT RESULTS)
• Un-deploy

Considering that each AC will participate in one or many assemblies for provisioning a “bigger” solution (or richer functionality), ACs are interdependent at their “creation” phases (contextualise, plan, design, build). Imagine that a highly-efficient team is created by the careful selection and training of people.

Ideally, ACs are independent at their “operation” phases (deploy, run, monitor and measure). For example, a high consumption of CPU by one AC will have no negative effect on other ACs. Or, an AC may be stop, un-deployed, re-deployed and resumed without determination of the whole assembly performance.

But, the binding or linking of ACs into an assembly makes ACs dependent in accordance with their contracts. Up-steam dependency is related to the AC’s performance. Down-stream dependency may happen as well by imposing some ACs to be used. (Note: There are several techniques to reduce dependency).

Thus, autonomicity of each component will vary from more to less (independency, dependency and interdependency) at the different phases of the full life-cycle.

Structurally interdependent, behaviourally independent and contractually dependent (Note: there are behavioural rules like in a red-card football) – what a mixture.

Working together in assembles

There must be a set of common rules for AC to help ACs work synergistically together (as an assembly) for a common goal. I think about the following rules:

• each AC acts similar to services, 
• AC may have a particular specialisation: user-facing (interactive service), coordinator (orchestration, etc.), lawyer (decisional business rules), utility (basic functionality), resource (data, etc.), communicator (lightweight moderator), dispatcher (event handler?), referee (behaviour rules enforcer), porter (security service), registrant (naming services), etc.
• to work together, ACs follows agreed admission rules: naming, formally defined interface, performance, behaviour, etc. Admission rules for different assembles may be different.
• in particular, ACs may have to agree using some common ACs with assembly-wide functionality.

Must AC be small or not? Ideally, they should follow SRP.

In extreme, ACs may work together as a group of fully-universal-agents (no specialisation) or as a team of specialised ACs (some team-sports). Particular type of specialisation may be a coordination of ACs with “small or simple” functionality into an AC with “big or complex” functionality. (For example, combining “generate PDF”, “protect PDF by a digital signature” and “disseminate PDF” together.)

AC nomenclature

Let us try to use ACs for some modern ideas about a better application architecture (again don’t be fussy with the terminology) as one of them cites below:

“A modern application is a functional ecosystem comprising a loose association of apps and services. Apps implement the application front end (user-facing) to support a specific functionality on a particular type of device and interaction medium, and services implement the application back end. Together these apps and services support a particular business domain.” (Note, also RIA were talking about this).

I think that the following types of AC are necessary to cover the majority of “modern applications”:

• various resources (primarily, data) – this is a typical data-access AC.
• utilities – this is a typical data/documents transformation AC.
• data/documents role-based mini-portal (select data/documents and initiate an operation on them) - this is a user-facing AC.
• functional portals (select a function and execute it on some data/document) – this is a user-facing AC.
• short-running (or synchronously executed or near-immediate completion) operation – this is a user-facing AC with some logic and invocation of some other ACs.
• long-running (or asynchronously executed) operation – this is a orchestration-like AC for long-running coordination of people and ACs.
• stateless and idempotent composition of some ACs for a composite operation – this is a low-code aggregation for invocations of other ACs.

Archetypes of application which can be constructed from ACs

Data-centric application archetype

Typical usage: browse a data repository, select and execute an operation.

Document-centric application archetype

Typical usage: browse a document repository, select and execute an operation.

Example: document management systems

Operation-centric application (with short-running operations) archetype

Typical usage: browse a static list of operations, select an operation, associate with it some data/documents, execute this operation.

Example: employee portal

Note: all operations are short-running – they are completed in less than a few minutes (so a person can wait for their completion in front of the screen).

The static list of operation is role-dependent.

Operation-centric application (with long-running operations) archetype

Typical usage: browse the static and dynamic lists of operations, select an operation, associate with it some data/documents, execute this operation.

Example: employee portal.

Note: all operations are long-running – they are completed in a few days / weeks (so a person cannot wait for their completion in front of the screen).

The static and dynamic lists of operation are role-dependent.

Real applications

There may be a mixture of mentioned above archetypes.

Conclusion

Do you see other types of application? Do you know other specialisations of AC? Please share.

Thanks,
AS

Yet another definition of enterprise architecture #entarch and metrics for enterprise architects

My short definition of #entarch from the viewpoint of an enterprise architect

Enterprise Architecture (EA) is a system-thinking applied management discipline about essential decisions for coordinating people, processes, projects and products in 11 dimensions:

1. focus space (biz unit, enterprise, country, etc.)
2. architectural space (business, information, etc.)
3. time span (project life-cycle, solution life-cycle, enterprise life-cycle, etc.)
4. sector span (various industries)
5. problem space (re-structuring, rationalisation, M&A, standardisation, etc.)
6. solution space (from a concept to operations - like ZF rows)
7. cultural space
8. practice space (are you theoretician vs methodologist vs practitioner?)
9. media space (physical vs analog vs digital)
10. financial space (number of zero in the budget)
11. people space (top, management, middle-management, super-users, workers)

Candidates:

• environment
• legal 
• socio-technical vs technical system
• CX span (touch point, journey, storytelling, lifecycle)
• social space (gender equality, consensus building, conflict resolution)
• person span (individual, house, personal cars, public places, etc.)
• technology ?

Using the definitions below:

• System-thinking applied management discipline is an applied management discipline which uses system-thinking approach.
• Applied management discipline is a management discipline which applies scientific knowledge for solving practical problems.
• Management discipline is a discipline for the better management of the enterprise functioning in support of the enterprise goals.
• Discipline is a coherent set of governing rules.

And the self-contained definition will be:

Enterprise Architecture (EA) is a coherent set of governing rules for the better management of the enterprise functioning in support of the enterprise goals by applying system-thinking scientific knowledge for solving practical problems in coordinating people, processes, projects and products in 11 dimensions.

.......

This definition can be used as a metric to qualify enterprise architects. In my books, an enterprise architect must comply with the following:

1. focus space: work for 1000+ people; 
2. architectural space: able to contribute to all architectural domains; expert knowledge in 2-3 domains
3. time span: have experience with complete enterprise life-cycle
4. sector span: min 5 different sectors experience; able to find similarities between sectors
5. problem space: leading min 3 critical enterprise-wide changes
6. solution space: comfortable in min 4 rows
7. cultural space: know culture specifics for the majority of staff members
8. practice space: be good at least in 1 of these roles
9. media space: make fully digital a whole company (100+ people)
10. financial space: 1 M budget minimum
11. people space: able to talk to everyone to explain how EA will address their concerns and change their working habits for the better

Thanks,

AS

#BPM for #SOA+#ESB+#API and #cloud (#PaaS and #SaaS)

Some recent reflection how some of TLAs should work together.

 Warning: slide # 7 has animation.
 

Thanks,
AS