Published in 2017 on organicbusinessdesign.com
The enterprise element that is missed, but suspected by many
This article continues our publications about united architectural and operational viewpoints on the corporate business.
EVERY FORMAL BUSINESS organisation has its intrinsic architecture [1]. This is the fundamental outcome from the Theory of Systems.
It is not about an architecture of the building that your company occupies, it is not about a team of colleagues called Enterprise Architects sited in IT Department and it is not about IT at all. This is the architecture of your business system.
In many companies, their owners and managers are unaware that they deal with the architecture within their business system. Actually, they consider a term “system” too technical, but they clearly recognise the moment when an “enterprise” as endeavour becomes an “enterprise” as business, i.e. formalised endeavour; the latter constitutes a system. They think they work with people and it is correct. However, these are not any people but only those who fit with particular business system. The rules of this fitting are derived from the Architecture of Business (AoB) of your organisation. Before you put off so technical article, let us tell you that it is very you who architected this organisation. We will try to explain when and how you did it, but it seems you have not taken advantages of it yet.
All right, assume you agree (for a moment) that there is an architecture in your business that for years of working there you did not notice. There are reasonable questions: what does this architecture consist of, what can we do with it, who and how can use it and whether this knowledge can help you and your organisation to gain more revenue or, at least, solve some of your problems.
In this article, we intend to answer these and a few relevant questions. Jumping ahead, we can say that AoB can be used for solving serious business and management problems caused by accelerating dynamic environment that we had not experienced before.
A Spiral of WHATs and HOWs
WE TRY TO START at the beginning and answer a simple question – what is more important for an abstract company (commercial or non-profit): “what does it do in the market or how the company does it”? A politically correct answer might be – “both, neither of those options is more important than another one”. A not politically correct answer is “what we do is more important than how we do it” – his is a bearded truth (famous Peter Drucker said, “There nothing so useless as doing efficiently that which should not be done at all” [2]). Many ‘practitioners’ prefer to declare a politically correct position, which usually allows doing nothing but looking good.
Let’s assume, you have decided to plant a tree in your back-yard or in a park. This means you have identified “WHAT to do” – to plant a tree. The opponents can say
– you might be not a good gardener and, as a result, you would plant the tree in the wrong way and the tree would wither. That is, how you work, how you perform or implement your task is very important for the outcome.
No doubts, this is very important; but this does not answer the question. It is amazing how quickly incompetent people learn to say right things instead of answering the question…
Decide yourself: if you would not have an idea to plant a tree, no tree would be planted at all regardless whether you are an experienced gardener or not. In other words, if “WHAT to do” is not defined first, you would get nothing out of it. At the same time, you can read instructions for proper planting and follow them, or you can hire a professional gardener and make the “HOW to do”-part the right way. The conclusion is this: without “WHAT” first, not even perfect “HOW” would lead you to the needed/expected outcome. Usually you have options in how to do things if you know “WHAT” to do; if you do not know, no “HOW” will help you.
Thus, our journey starts with “WHAT”, then it goes to “HOW”. However, we know that a realisation of relatively complex “HOW” usually requires several implementation steps, each of which is a smaller “WHAT” leading to its “HOW”, and so forth.
This is the logic of activities of any business organisation: a few fundamental, core elements (defied in the Corporate Business Model when the company just established) start their implementation streams of less important elements. Some of those elements can be retired over the time, sold, exchanged, or re-placed while the core elements remain and the organisation sustains. The core elements also advance, but at slower pace, which allows the organisation to evolve.
Thus, before talking how we can use AoB, we need to define or understand what it is.
Many practitioners exercise the approach that tries to describe or even to define a tuning via how people use it. Frequently, when those practitioners want to replicate known thing hoping this would help them to gain a success if the prototype had it, their attention is fully occupied by the thing and this constitutes a costly trap. Since they do not know what they do and have no information about the prototype context (where it was successful) or ignore it, their chances of getting a success by ‘copying’ in their circumstances are questionable.
We used to rely on best practices and training recommendations when forgetting the major assumption: our execution context does not change significantly from their ones. If the context has changed considerably and we still do not know what we do, we unable to evaluate suitability of de facto deprecating best practices and we head to troubles.
The fundamental difference of this work from many analogous is in that we inaugurate the subject of architecture, particularly, architecture of the system formed by any business organisation. Only then we will observe how to deal with it.
Architectural Elements in the Business System
SO FAR, BUSINESS MANAGEMENT is an art rather than a science. Experienced senior managers know that in many cases they are not absolutely confident in whether their directions would work and what consequences they can cause. This phenomenon has been explained many times by different causes that frequently included people, resources, organisational structures and others. We believe that one of the major reasons of this uncertainty and potential failure relates to the architecture of the company’s business system. If a new initiative or order contradicts the AoB of the organisation, the system’s architectural elements will resist changes. Here is why.
In a cohesive integral system, the non-architectural elements are either depend on the architectural elements, or derived from them, or exist because of the logic/needs of them. The architectural elements should be not only fundamental to the existence of the system, but also should be independent from non-architectural elements within the system or outside of it. For example, architectural elements should not disappear due to an uncontrolled event somewhere; if they do, this can destroy the system, i.e. the business. The non-architectural elements of the system can come and go. Also, the architectural elements are interconnected aiming to a shared goal while non-architectural elements may have different goals, purposes, agendas.
At the time of writing this article, we have identified only two elements of a business organisation that are architectural. They are business functionality (functions, features, action, operations) and business information (semantically meaningful data) that the business functionality operates with. So, the business functionality and information form the intrinsic architecture of any business organisation, in any industry, anywhere in the world. Yes, this is a universal matter. Moreover, while companies in the same industry domain have similar architectural elements, the combination of actual architectural elements in each individual company is unique. This is why companies in the same industry can compete. We are open for challenging any other elements of a business organisation in order to identify them as architectural if somebody would propose such ones.
On several occasions, we participated in the debates on whether ‘people’, ‘organisational structure’ and ‘operational structure’ in the business are architectural elements. With no doubts, ‘people’ is the fundamental element of a business system. Nonetheless, we have already seen profitable financial organisations that have a couple of people as the owners/partners, no employees, and still working very well. Those partners outsource all operations to other companies and, when needed, re-contract the vendors. The company itself does not change. In more and more industries people are replaced by machines and automated management (decision making) means. Also, people depend on many external factors like laws, wars, weather, etc., i.e. they can come to perform the job, or not. Moreover, many employees come in the company for a pay-check – they are not interested in the goals of the business, they have personal agendas that may be even orthogonal to the objectives of the business. Thus, we cannot consider ‘people’ an architectural element of a business organisation.
Regarding the organisational structure of the company, it can be relatively steady only in the companies operating in a slow changing market. To survive and even prosper in the dynamic market, the organisational/operational structures of business should be flexible and reactive to the market change at a pace of those changes. This flexibility seems the only one option for a company to survive in such a market. If an organisational structure of the business does not follow the changes in the market, this quickly generates a gap between business capabilities of the company and market imperatives. The AoB allows to address market dynamics at the same priority as the corporate strategy thanks to the mechanisms embroiled in the AoB Practice.
An organisational structure of the business is a classic non-architectural element. Apparently, it is a supportive element, which is used as an instrument for aligning the business to the market. The better current business organisation and operations reflect the AoB and its solutions, the more stable and relevant to the market needs the company becomes. If the market changes frequently, the organisational/ operational structures can change at the same pace. If your company is in sync with your market, your chances for the competitive advantage in this market have higher probability.
If existing organisational structures cannot be quickly modified because of certain management principles, these principles should be changed first. This is possible to do with no harm to the company because these structures are not-architectural, i.e. should be easily replaceable. Recall that the same “WHAT” can be gained with several different “HOWs”.
It seems that complex hierarchical management structures ruled by the number of direct reports (e.g. a number of direct reports should be not more than 5) and single accountability to the upper manager are not flexible enough for working in dynamic market. Such structure is efficient and effective in the types of manufacturing production of the same things for a long time. When a business capability to adequately react to the changes becomes one of the major competitive advantage, the principles of orientation on service should supersede. This links back to the source of revenue – change in the market usually results in the change in consumer demand. A topic of business organisation, based on service-oriented self-sufficient Business Units operating within internal corporate (regulated) market and united by a single source of funding, requires a special separate publication while the initial thoughts about it are published already [3].
In a slow-moving market, a mismatch between the corporate strategy / AoB solutions and corporate operating model can result in a negative performance, which could be compensated the next time. It is unpleasant but manageable situation. In a dynamic market, there may be no ‘next time’ and such mismatch can cost the company its existence. This justifies a necessity to look at what operating model should provide, not only on how it will work.
An Advanced Understanding of business capability
ANY COMPANY CAN be described top-to-bottom via what it does, when and where it does this and for whom (5W).
This is a snapshot description. Such description remains valid until it is in sync with the environment. In such situation, planning and design of corporate Target Operating Model (TOM) can be done bottom-up: starting with BU or even Groups and passing proposals to Division, LOB and to C-level management. Such practice caused a believe that this is the “right way”. Since people dislike changes (instability) their proposals cannot significantly deviate from their current doing and usually aim to improve how they currently work. In such atmosphere, a meaning of business capability is, indeed, what the business does today. The basis assumption of this approach stability of the business environment.
It is assumed that the management of the bottom-up operational structure knows the best how it works and what is needed to do this better. The source of potential changes here is the upper management level and the mastery is based on collected experience. Are we sure that all those managers are competitive in the market and they know what is “outside of the window”? Can they make objective decisions about directions of their work and reasonably answer a simple question of why they do what they do? What are the motivations for them to be in sync with market trends? The old saying says, “One cannot do today’s job with yesterday’s tools and be in business tomorrow.”
If the environment changes fast, small operational adjustments become inadequate. In such context, when one manages complex business solutions full time, his or her awareness of the market objectives becomes fragmented and insufficient for building the corporate strategy. The faster market changes, faster the past experience based competitiveness degrades. The description of a business still can be based on 5W, but it is expected that the content of the description updates frequently as well reflecting the updates in the operations. If this does not happen, the company is likely in risk.
Thus, we need a mechanism that would be strongly tied to the dynamics of the environment and enforced that the company should do tomorrow to survive the changes. Jack Welch said, “If change is happening on the outside faster than on the inside the end is in sight”.
Implied mechanism exists and based on relatively new interpretation of business capability. In a dynamic market a value of what the company does today is less important (because it is already happening in current execution context) than what the company can do – in a year, in a moment, in a week or next quarter and in which circumstances. In essence, the new meaning of business capability is:
- business capability is an ability of a business entity – a person or organisation – to produce predefined Real World Effect (outcome) under certain conditions in particular business execution context,
where
- Real World Effect is “a measurable change to the shared state of pertinent entities, relevant to and experienced by specific stakeholders of an ecosystem” (OASIS RAF for SOA, 2012)
- Execution Context is “a set of technical and business elements that allow interaction to occur” (OASIS RAF for SOA, 2012) between the entity and its environment.
We have realised given definition of business capability via three ultimate elements:
1) Business Functionality that should be realised
2) All types of resources, which will be needed for the realisation that, particularly, include people, management, technology, natural resources, finance, etc.
3) Monitoring of the resource availability inside and outside of the company
The rule of thumb here is: no resources, no capability. For example, a business unit does not have a capability to realise certain initiative if it does not have funds to do this work; the initiative exists while the capability does not.
The major consequences of described understanding are:
1) Such capabilities aim into future, which eventually becomes the current reality. Therefore, we have to become ready for emerging changes in the market.
2) We can consider internal and external resources when we design the capability. This leads our business to the high-level flexibility. An absence of resources inside the company should not prevent it from having the capability if external resources can be hired. We can plan and compose/recompose resources for supporting our capabilities, which we couldn’t consider before, and this can provide a competitive advantage for us.
The business capability is set around the architectural element – business functionality, i.e. explicitly linked to the Intrinsic Architecture of the business system. As a result, we have a scheme: when one modifies Intrinsic Architecture/business functionality, the set of business capabilities of the company is modified, which leads to the change in the resource realm and the entire business system changes. This is the key to managing business organisation in a dynamic market.
AoB Practice: working with Intrinsic Architecture
A concept of Architecture of Business includes a notion of architectural practice (AoB Practice). Actors in this practice are in the roles of Business Architects, Approvers and Delivery/Operational Management:
· Business Architects are those who architect the business by defining and design modifications to the Intrinsic Architecture of the business organisation and govern related implementation
· Approvers review and approve/disapprove the architectural plans and solutions for the modification of Intrinsic Architecture and following TOM
· Delivery/Operational Management contribute in the business capability design in the area of resources. Consequently, Delivery/Operational Management lead realisation of architectural solutions via design and implementation of TOM in line architectural solutions.
An AoB Practice includes, to list just a few:
- · Principles
- · Policies
- · Tools
- · Methods
- · Operational activities
- · Research of the market trends
- · Support of the process defining the corporate strategy
- · Definition of business capabilities
- · Models and compositions of business capabilities
- · Monitoring the capability resources
- · Defining and verifying architectural solutions for the corporate strategy
- · Defining requirements for implementation in the TOM
- · Governance of the architectural solutions design, TOM design and implementation
- · Cooperation with Delivery/Operational Management, Financial and Marketing functions.
The outcome of the AoB Practice comprises:
- · architectural solutions
- · plans for deploying these solutions over the time and locations
- · development of requirements for implementation
- · governing principles and policies
- · verification and prioritisation of market change adoption
- · adjustment, re-definition and new definitions of business capabilities depending on the market changes.
The architectural solutions and related requirements combine strategic business imperatives dictated by the corporate strategy and trends of the environment changes. The new definition of business capability helps in this a great deal because it allows loose-coupling between business functionality and related resources as well as ability to engage external resources on as-needed basis and without necessary partnering with the vendors.
Business capabilities represent the major instrument of Business Architects. They decompose the goals and objectives of the corporate strategy into interdependent structures of tasks, i.e. in the structures of what should be done in functional terms in order to deliver the strategic goals and objectives. The functions are wrapped in the business capabilities and combined in new models, which are then challenged and optimised before being recommended got implementation via TOM.
The major driver of decomposition and re-composition of business capabilities is a value proposition. Particularly, depending on the type of business organisation, a value proposition can vary significantly. The new architectural models have to address propositions that benefit as business owners/shareholders as customers.
For instance, value propositions, defined in the capabilities, and respectively the architectural models/solutions can be focused on:
1) Increase revenue
2) Increase benefits
3) Reduce cost
4) Keep the value the same, but for different customer base.
Particular focus of the value proposition is defined in the corporate strategy; the architectural solutions and TOM implementation only make sure the values are delivered to the consumers and stakeholders. However, in contrast with the situation a few years ago, modern market can change for the time of constructing and realising TOM, and the meaning of the value can change as well. This creates a challenge for traditional use of Value Chains and Streams and calls for the new methods.
Architectural Governance Throughout Practice and Implementation
ARCHITECTURAL GOVERNANCE IS not a new term – it is known in IT and its Enterprise Architecture function. However, only the most progressive CIO allows this governance to penetrate the project management practice; in all other cases the Managers take over the governing role.
Learning from this experience, the Architectural Governance element of AoB states that an architectural governance function starts from the AoB itself and ends in the last phase of every delivery project, in both business and technology. Architectural governance should be separated from the management. Overall, governance sets the rules and management plays by those rules.
The purpose of AoB Architectural Governance is promoting and preserving realisation of the strategic goals and objectives as the corporate executives see them throughout the enterprise. This governance controls that the realisation of architectural solutions would not deviate from the solutions in an uncontrolled way. The architectural governance is supported by the superiority of architectural decisions over a project delivery. The dynamic environment does give us a second chance: TOM has to deliver what should be done and usage of external resources (if the internal ones cannot deliver) becomes critical for the success. This is another indispensable difference of the AoB Practice/Governance from many currently executed.
There are four major parts of AoB Architectural Governance:
1) Principles
2) Policies
3) Metrics
4) Reviews.
The principles are the long-lasting expressions of the corporate business objectives and they are usually formulated in coarse-grained statements. Policies detail the principles and cover all aspects of business design, structures and operations. Policies are the most dynamic part of governance and are supposed to reflect changes in the company’s operating environment.
Metrics are standardised or agreed characteristics that reflect compliance of the entity to the policies. Management enforces policies while the level of compliance shows how the enforcement and the policies themselves are effective. Compliance can include different types of metrics. For example, behavioural metrics, which are measurable quantitative characteristics of the entity. The performance metrics are also known as key performance indicators (KPI) and used in the performance and balanced scorecard method; they are meant to demonstrate how particular business activities or the entities are doing against the objectives.
Adherence to all types of policies is the subject of architectural reviews. A recommended Architectural Governing Committee (AGC) constantly monitors metrics and related compliance. The AGC also produces compliance recommendations and grants temporary exceptions. However, the exceptions are not a regular method of avoiding compliance, but an extraordinary instance. The AGC has the authority to interrupt any design or development/delivery project if it demonstrates a poor compliance or the compliance appears impossible. In the last case, the architectural solution should be reviewed and the question about feasibility of implementation of that solution should be answered.
AoB Implementation
THE FINAL PART of the AoB concept is an implementation of architectural solutions and decisions. The solutions are presented in a form of business capability compositions spread over time and geography (where needed) and documented in the capability Deployment Plan and Implementation Requirements. The implementation of architectural requirements is a corporate Target Operating Model. The optimised TOM simultaneously addresses the strategic objectives and the dynamics of the surrounding economic environment.
We distinguish between business imperatives and architectural requirements for TOM implementation. Not all imperatives can be included in the particular corporate strategy. Also, some business capabilities might be limited in legal, political and physical resources that make certain imperatives unrealistic in the given execution context. The architectural requirements consider ‘doability’ factor. It is included in an interactive feedback process where the architectural solutions and even strategic objectives can be refined based on resource availability at the certain point of the Deployment Plan and TOM implementation.
Architectural requirements dictate the design of the operational means such as value streams, business processes and services as well as adaptive cases. Due to involvement of Business Architects, the construction of TOM is optimised for particular strategy and environment, where this strategy should be realised and operate. We propose a 5-Step Framework for building an optimised TOM [4].
Per this framework, the Operational and Delivery Managers are actively involved in designing business capabilities (how they will work) in the part of resource planning and reservation while the capability are defined (what to do) by Business Architects. This is the central point for the successful work on the TOM design because senior and even middle-level managers become familiar with the required functionality and its internal dependencies at the early stages of architecting business. The Value Chains and Value Streams, to be included in TOM, are initially designed and validated in the architectural solutions based on the different value propositions.
The significant difference of this approach to TOM development from widely practiced one is in that the strategic initiatives come top-down in already integral and cohesive form with known interrelationships of the future business activities. The major needs for the resurrection of this “old” top-down approach are:
a) a shortage of information about the market trends among operational management
b) a need to preserve the interests of the company above the interests of its individual divisions
c) a necessity to react quickly to external changes in integral manner across the entire organisation
d) a demand of monitoring competitiveness of internal operations against market offers and continuously calculate potential impacts and consequences.
All of these have to be done outside-in and across the internal administrative boundaries.
As the practice has shown, the contemporary management top-and-bottom command-and-control regime is incapable to deliver for the mentioned needs. Nonetheless, the level of company responsiveness adequate to such needs can be reached. If all business units (people and operational management) from bottom-to-top of operational structure would unconditionally share the same motivating cultural view and accept of serviceability, massive and continuous changes can be accepted. In essence, a serviceability means that everyone services the needs of everyone else. Particularly, employees service the needs articulated by the management, managers the needs articulated by executives and all together service the organisation and its shareholders; Business Architects provide just a content of those needs.
As we mentioned before, an optimised TOM should include internal mechanisms for local adjustments (caused by changes) within the same operating model, which the majority of traditional TOM does not have. If a company would be able to operate successfully in a highly dynamic market, it will be also successful in the environment changing slower. The opposite is not correct and this is a common trap for all who try to follow the best practices from the past blindly.
Analysing different operating models, we can find that they usually include such aspects as Value Chains, value propositions, suppliers, locations, organisational structure, technology, information and management system, as well as human factor (skills and culture), processes/cases and communication channels. What many TOM and its designers omit is the impact of changes in the execution environment and its dynamics.
We argue that this impact is enormous, but it is not as obvious as when the corporate management decides to move to another market and/or geographic region. The impact roots in the effect of globalisation – governments around the world try to leash changes brought up by international companies and digitalisation; governments issue a huge number of regulations and laws. In combination with an immediate information about events taking place in the opposite side of the globe and their influence on the behaviour of local businesses, the increasing number of regulations makes the economic environment even more dynamic.
Which changes can be adopted by TOM on the fly and which of them require architectural re-design, have become one of the biggest challenges for both Business Architects and Operational Managers. In such environment, business values that drive operational changes in the company become “a dynamic variable” and require a special handling.
Our current models of the market trends and social reactions to changes are not ideal and contain a significant element of ‘unknown’. We can prepare our companies for this by designing our target operational and organisational structures, including the organisational charts and management systems, to be as flexible as possible. A business solution flexibility has a quantitative expression [3] and can be estimated before it is realised. At a glance, flexibility can be expressed via minimisation of the cost of adopting a change, delivery of this adoption to the market and the cost of adopting a change of the previous adoption. In other words, when implementing a change, the mindset has to be focused on how we will change this implementation tomorrow.
The flexibility can be assessed against different scale. However, this topic as well as the overall optimisation of TOM is a subject of a separate special publication.
Things to Remember and Apply
ARCHITECTURE OF BUSINESS is an architecture of the business system formed inevitably by an organisation or enterprise. It exists in the companies of any size, industry or location. It exists due to the existence of the system regardless an awareness or opinion of the business owners and managers.
A concept of Architecture of Business includes business intrinsic architecture, architectural practice, architectural governance and implementation in the form of TOM. Business Architects operate with intrinsic architectural elements of the business system such as business functionality and information. All other system’s elements depend on the architectural ones. Business Architects modify the architectural elements, causing chains of changes in the rest of the system. TOM implements these changes.
Practice of Architecture of Business occupies the space between corporate strategy and corporate operating model including its implementation. This practice analyses, models and defines what the company has to deliver via its operational model in order to realise the corporate strategy and, simultaneously, address the dynamics of the company’s operational environment. The higher dynamics of this environment, the lesser helpful the previous experience and best practices become to the survival and progress of the businesses.
While intrinsic business architecture forms the theoretical basis of the AoB concept, its practice and outcome in the form of TOM constitute its business value-added aspect. New interpretation of business capabilities links the theory with its application efficiency. This makes the company comfortable with such capabilities and well-equipped for the effective competition in the fast transforming environment. An ability to adopt changes the first in the market becomes a new competitive advantage.
A Complementary Annex
The AoB concept follows principles that define directions and constraints for the decisions, solutions, models, and activities in Business Architecture [5]. These principles heavily impact practice principles for the entire organisation, its operations, technology, marketing and relationship management. The core principles are:
1) Forming the enterprise business (architecting the business system)
2) Separation of concerns (architecture from its alternative implementations)
3) Transition orientation (from current state to the strategic target state)
4) Dependency on the Business Execution Context (reflection of the dynamic economic environment)
5) Authority (architectural solutions are what the rest of the business builds)
6) Abstraction (separation between business functionality and resources that might be used for its implementation)
7) Prescriptiveness for implementation (architectural solutions and requirements are mandatory for the funding flows and resource allocation for implementation of the corporate strategy)
8) Bi-directional communication (to and from CxO as well as to and from the rest of corporate business management and teams)
9) ‘Collaborativeness’ (several architectural design activities are performed jointly with the senior business managers, e.g. a design of business capabilities and blueprints)
10) Serviceability (one of the missions of Business Architects is to preserve the corporate interests above divisional ones and control they are serviced first).
Altogether, the AoB principles drive the business organisation into the future. On one hand, they include a demand for business flexibility and agility to market changes; on other hand, they are not anchored by the best practices of the past.
References
[1] Michael Poulin, “Are Standards Sinless?”. LinkedIn, Feb., 2017 https://www.linkedin.com/pulse/standards-sinless-michael-poulin-of-clingstone-ltd-
[2] Peter Drucker quotes from BrainyQuote.com https://www.brainyquote.com/quotes/quotes/p/peterdruck105338.htm
[3] Michael Poulin, “Architects Know What Managers Don’t: Business Architecture for a Dynamic Market”. ISBN 978-0-9575199-0-9, BuTechCon-Troubador Publishing. 2015 http://www.mpoulin.com/architects-know-what-manager-dont/ and Amazon
[4] Michael Poulin, Kirill Derevenski “Optimising a Target Operating Model through an Architecture of Business: a comprehensive – and revolutionary – approach to effective organisational adaptation to change in a dynamic market environment”. Pulse, LinkedIn. April, 2017 (copyrighted in May, 2016). https://www.linkedin.com/pulse/optimising-target-operating-model-through-business-michael
[5] Michael Poulin, “10 Questions to Business Architects”. Pulse, LinkedIn. April, 2015. https://www.linkedin.com/pulse/10-questions-business-architects-michael-poulin-of-clingstone-ltd-