A Simple Architectural Framework (ASAF)
In this section I re-analysing the approach taken by John Zachman, seeing if a different framework might exist, and applying this thinking in both my commercial life and in the development of the open-bpm architecture.
It is interesting that recently in my commercial work I have concentrated on information architecture (working in a small enterprise architectural team) and of course the open-bpm architecture is process centric. I think that this dichotomy adds to the work here. Just because we are process centric does not mean that we don't need to handle all situations.
In addition key aims are to have ASAF implicitly hint at a methodology, and address the concerns discussed in the Zachman Framework section. Also the ASAF needs to have relevance for open-source projects and also, therefore, software houses. The first parts discuss the development of framework.
Perspectives and Aspects
The concept of perspectives or views of the architecture suggested by Zachman is very powerful and certainly something we want to build on.
The perspectives give different views of the architecture; what we need to consider is what perspectives we need.
Also John Zachman's perspectives are recursive; the constraints of higher ones apply to those below. However technology now commonly affects business aims and processes, and so we need to define a more complete model where technology impacts business aims.
I call the columns in Zachman Frameworks aspects - all the aspects together give a complete description of a perspective. There are six publicly defined (who, what, when, where, why and how) however more and different ones can be used within the framework.
Can we define a set that is meaningful across our perspectives, or will each perspective have specific aspects (as well as a core common set)?
Processes
Business processes seem a sensible way to approach architecture. Although this site has a BPM focus, I believe considering business processes as a fundamental approach in most, if not all, situations.
ASAF focus on business process is designed to provide cohesion in the architecture. It also provides the "clue" to methodologies as to how the framework can be completed.
Business processes include activities like software development and user support. This consideration shows how powerful and complete the architecture will be when business processes are used to ensure complete coverage of the enterprises activities, or indeed of a delivery project.
An issue for the architecture is to decide the level of process definition to use.
One extreme is to define the whole business as one process, more reasonable is to define a set of almost generic high level business processes: sales, purchasing, HR, Finance, production, development etc.
The other extreme is to define each possible process in the style of a workflow project ("Application for a car loan received via post for an existing overseas customer", ...).
The real answer to this question is that the methodology being used should define the process level, for an example see "A Simple Architectural Methodology (ASAM)" on http://www.open-bpm.org. However it should be noted that at a certain process level the majority of the frameworks cells for the sibling processes will be identical. This being the case the value of the architectural work being undertaken at that process level should be questioned.
It is theoretically true that for a complete architecture the process level should not matter, all the details should still be recorded (or recordable). The process view (and therefore level) is just a tool to organise the presentation and development of the architecture and to prove completeness.
However, in practice the level of detail recorded in the architecture and the level of process definition must be related. For the framework (ASAF) this relationship is expressed as between the perspective and process depth. Each perspective can have its own process depth. It is expected that this will be used to avoid repetitive information and provide appropriate detail to the perspectives.
Channels
The way that enterprises interface with their customers and partners has become more complex since the growth in popularity of the Internet and the use of call centres.
Channels, so far as a business model is concerned, can be classified as:
- Self Service. Includes web sites, some IVR, automated tellers, PC applications provided to customers that communicate to the business. This is typically expensive technology because all failings of the systems become visible to external customers, who also need to be considered untrained and untrustworthy.
- Anonymous Servicing. In this scenario the customer is assisted via an agent who is not known to the customer. The common example is a call centre where an incoming (or out going) call is routed to any free call centre agent who happens to have the required skills. Another example is where a customer is assisted by an assistant in a large shop or bank - the customer and assistant have no lasting relationship.
- Assigned Contact Servicing. In this scenario the customer is assisted by the same agent (or limited group of agents). The assigned associate can either handle the customers requests directly or act as a broker representing the customer with other agents within the business. A relationship develops between the assigned agent and the customer allowing the customer's context (and indeed the businesses) to be implicitly understood. On the other hand customer requests have to be routed to the assigned agent which can be difficult, it also implies a level of resourcing, "wastage" and complexity over Anonymous Servicing. Examples of this include "personal banking" and the relationship developed between customers and front office staff in small businesses.
In the last very few years the Internet (specifically Web Sites, but in future other "connected" technology) has allowed the development of the self service business channel from niche to the mainstream. And of course the driver for CRM initiatives is to enable (or at least provide the illusion) of an assigned contact.
Is a channel strategy really that important for a business model and architecture?
business model or strategy often segments the business customers and targets different offerings to those segments. Part of that differentiation is the [different] channel strategies applied to the different segments.
For example a bank's decision to provide private banking services or "platinum" level offerings is profound. A key part of these offerings is the ability of the client to have a single contact at the bank. For private banking this contact will be a senior investment professional and for platinum offerings the contact is likely to be a much cheaper employee. However in each case this is much more expensive and provides better service than that offered to other customers. To cover the cost it is important that the customers getting this service pay for it (by using the banks investment services, having large deposits or loans, or by subscription).
Clearly this will impact the operations of the bank but it also can effect the way the bank is perceived by the market; how will other customers react to these services giving others better service?
- Some banks use these offering explicitly to attract high profit customers and make the bank unattractive (or unapproachable) by normal customers (possible example, Coutts Bank).
- Some will attempt to "hide" these offerings from customers in segments for which they are inappropriate (possible example, HSBC).
- And some banks will decide not to have these offerings at all as they are banks for the people and in the name of fairness and operational simplicity! (possible example, Egg)
This hopefully explains the importance of channels to a business's strategy. In addition the effect on business operations and costs is clear as are the implications on Information Systems and Information Technology (in short the IT Architecture).
Is the channel strategy always important?
My example and discussion in the above section show the importance of the channel strategy in some cases but does this cover all businesses.
I believe that for businesses which deliver a range of services to large numbers of customers (especially consumers) and probably partners then the channel strategy is essential.
It can be argued that for businesses that sell to relatively few [large] customers or which are limited to a single channel possibly a channel strategy will have no relevance.
However it should be noted that even small shops can have a mail order department. More relevant to an enterprise, the number of interactions between organisations and people within organisations needed to support many business processes imply complexity and cost that has to be considered.
For example, a company like Oracle sells to large enterprises via account managers and account teams. However technical support and financial receivables are two business processes that are available via different channels (some independent to the account team). Also the sales process to smaller clients of Oracle are supported on-line and do not get the same account services. This is an example of customer segmentation and channel strategy that certainly impacts the operations and IT architecture of Oracle.
How should the framework (ASAF) handle Channels?
There are four obvious options for handling channels in an architecture.
- As a scope delimiter. In this case we do an architecture for each channel and presumably one or more for internal systems. This is actually quite common, usually as the call centres and web-sites have been bolted onto traditional IT (by "specialists" rather that the core IT department) with its own architecture. To decide to do this "from new" or to continue with it creates problems because you don't get a end-to-end view of the architecture. Today the call centre and web sites are usually essential parts of the business and not bolt-ons.
- As a major business process. This is a slightly more sophisticated version of the above approach and is probably equivalent in ASAF where the architecture is considered demarcated by business processes anyway. In many cases business processes can be seen to be totally aligned with a specific channel therefore this approach can not be rejected out of hand.
- As an aspect of business processes. This solution defines channel strategy as an [important] aspect of a business process which seems sensible. Also channel strategy can be different for different processes and this is well supported with this approach. Often channel strategy is related across processes (e.g. because of a common customer segmentation) and this may cause problems (e.g. repetition, inconsistencies, and no single view of the channel strategy). Of course channel is not relevant for all processes (e.g. internal processes). An issue must be how to get a joined up view of the technology and systems supporting a specific channel. This is a issue for the whole framework where you have systems and technology spanning business processes. In ASAF (similarly in the Zachman Framework) a perspective oriented view across processes addresses this concern.
- As a lower level sub-process. In this case a business process (e.g. Support) is subdivided into channel specific sub-processes (e.g. Self Service Support). This is always an implicit option available in ASAF.
A mixed approach is used in ASAF. It defines channel as an aspect of the business processes. To allow for consistency and avoid repetition, these aspects can refer to a central description of a channel strategy and in this case is represented as a separate business process. Because of the relationship between perspective and process level within the framework, we do not have to consider channel as an aspect for every perspective. And we can also divide processes up as channel specific sub-processes for certain perspectives.
Matrix
Rather than just specifying very generic aspects (what, who, why etc.) we can define a set which has specific meaning and relevance in the context of business processes.
Motivation (why)
This is the purpose or reason for the enterprise supporting the business process.
Parties (who)
The organisation(s), group(s) or individual(s) concerned in the process (depending on perspective).
Location (where)
Where the process is worked, the location of the parties and systems involved in the process.
Process (what, when, how)
The steps required to take work through the process. What order are the steps done in? What branches exist? What business rules need to be applied?
Channel
The business channels that the parties concerned in this process use.
System
The IT systems (and interfaces) supporting the process.
Timing (when)
Any timing or periodic characteristics or concerns of the process.
Quality
The service levels associated with the process, for example the end-to-end completion time for n% of the work instances.
Cost and Value
Business cost and value models for the process.
Volumes
The volumetrics concerning the process. The number of work items (process instances) that need handling in a period, peaks and troughs.
What are the perspectives of a business process?
The perspectives that Zachman defines in his framework are: the planner, owner, designer, builder, vendor / sub-contractor and the product or enterprise itself.
Considering a business process we can re-analyse this list.
Planner
The Zachman meaning for this perspective is scope (contextual) which is valid when considering a business proess.
Owner
Business Model - conceptual.
When considering business process - we can think of the owner as the organisational unit responsible for the business process. Of course, a process will often span organisational units. The question is whether these other organisational units are stakeholders in the process or whether in an effort to define an end-to-end process we have really combines two or more processes. A process architecture cannot ignore essential organisational boundaries. In short, we are implying here that a process should have a single Owner and therefore Owner Perspective - there may be exceptions (but these should be exceptional ...)
Stakeholder
As just mentioned a business process often spans organisational units, and these (where they are not the Owner) are clearly stakeholders in the process.
In addition, other parts of the organisation may be stakeholders because they require the outputs of the process. In our process centric model, this means generating a required input for another process - even generating (and, specifically, distributing) shareholder value is a business process.
Designer
System Model - Logical
Builder
Technology Model - Physical
Vendor / sub-contractor
Detailed Representations - out-of-context
Product / Enterprise
The Functioning Enterprise
In this context we are talking about the work items flowing through the process.
What aspects are relevant for each perspective?
Influence of technologies on processes (changing process solutions and removing and adding processes).
