14 Jan Segregating Layers of Intelligence
Layered Architectures
Layers appear regularly in my blog, whether it’s layers of the brain, layers of processing nodes in artificial neural networks or layers in systems architectures. Layering embodies important patterns in the inexorable move toward a knowledge economy with knowledge systems. In today’s post, I’m going to talk about what layering brings to enterprise systems architecture and intelligent system design. Independently operable components organized in layers give solution designers and managers reusable components that reduce the cost and increase the speed of improving outcomes, and adding capabilities to empower knowledge workers.
“When designing the software architecture in a client-server system, you must come up with a way to divide the labor among team members. Your architecture must also be simple enough to be easily explainable to new team members, so they can understand where their work fits. In looking for an application architecture, many developers have looked to the pioneering Model View Controller (MVC) architecture. However, MVC is not the be-all and end-all of object design. While a proper architecture should address the concerns addressed by MVC, and may trace its descent from MVC, modern software systems must also address issues not covered by classic MVC” (Cunninghams on layers). Understanding and engineering this can make for one sweet layer cake!
| Understanding Context Cross-Reference |
|---|
| Click on these Links to other posts and glossary/bibliography references |
|
|
 |
|
| Prior Post | Next Post |
| What’s in a Decision | Just In Time Knowledge |
| Definitions | References |
| brain layers | Schank Nielsen Norman Group |
| artificial neural networks | Sowa Cunninghams on layers |
| separation of concerns | Allemang TechTarget |
There are many ideas about what layers are needed and how a layered architecture should be organized. I do not suppose that there is an ideal architecture that will fit all systems or suit all organizations’ needs. Rather, modular components, loosely coupled where possible, form adaptable and reusable capabilities that can independently succeed, grow and fail without damaging other capabilities in the overall architecture or portfolio.
The little boxes icons show modular process components. The cylinders represent information such as databases, rich media files or documents. The distributed content access layer, for example is an advanced data access layer supporting “separation of concerns” by giving services in other layers a single set of services to request and receive content form databases, documents and other sources. This allows system owners to more easily change or augment the backend physical data storage technology.
Not all the components are needed to deliver capabilities. In fact, even after implementation, it is often possible to take some services offline without interrupting core functioning of the capabilities. In the diagram above, the little yellow stars indicate the minimum core components needed for operational continuity (also ♦ in the layers table below). It is often possible to implement capabilities in a minimal configuration, and add components and services incrementally to increase the intelligence, usability or effectiveness of the system.
What is in the Layers of Intelligence
The components in the illustration above could be defined as follows:
| User Experience Realization Layer ♦ | UX is more than screens and look and feel: it embodies the whole process running from a thought that brings a person to the computer, to their satisfied departure. 'The first requirement for an exemplary user experience is to meet the exact needs of the customer, without fuss or bother. Next comes simplicity and elegance … a seamless merging of the services of multiple disciplines, including engineering, marketing, graphical and industrial design, and interface design' (Nielsen Norman Group)." |
| User Experience Management Layer | Static user experiences need no additional layer. When tailoring the experience to the user becomes important, user profiles that adapt display, process and secondary offerings, and that dynamically adapt the process flow to the actual dialog in real time are needed. They require management functions that are ideally implemented as an isolated layer that may be disabled under certain conditions. These capabilities are now widely used in online sales and marketing. |
| Interaction Services | This is another optional layer that isolates business services, especially those supporting multiple different interaction types, from the presentation layer(s). For example, a business service that sells widgets to other businesses or directly to consumers may use the same set of transaction services, and use the interaction services layer to determine if an invoice or a receipt is created. Services in this layer may use generic taxonomy or user specific profile information to differentiate. |
| Business Transaction Services ♦ | This set of services constitutes the core functionality of a capability or application. This is often called the business services layer, and in some architectures, there is a separate layer for transaction processing. If the system were, for example, a demand planning system, this is where the logic for calculating amounts of raw materials needed, lead times for ordering, substitute ingredients and budget constraints may be included. The layer may include a single module or many services. |
| Business Rules Evaluation Services | If you build rules in a consistent format, you can build a rules engine, such as a Rete engine, with common APIs that enable integration with multiple different services or layers, or even separate systems. Places where rules might be used to add intelligence and flexibility to a system include Business Services, Interaction Services, UX Management, Workflow, Model Management, Rules Management, Semantics and Search, Content Access, and, in short – you can use rules anywhere. |
| Workflow Services | Workflows may be user configurable, or may require trained designers, but they are usually built at a higher level than program code like Java or C++, and often include a graphical, or even drag and drop designer interface. Like a rules engine, common APIs make it possible to use workflows almost anywhere from the front-end UX Management layer, to back-end content and data movement services. Workflow services abstract branching: the core functionality of programming languages. |
| Knowledge Model Management Services | Knowledge models are not necessary to make capabilities effective or intelligent, but they help a lot. Like workflow services, knowledge model management services make building and adapting ontological or topological models visual and understandable. Graphical models, often with drag and drop interfaces are good representations for semantic networks (Schank) concept graphs (Sowa) and ontologies (Allemang) showing objects as named polygons and links as named lines." |
| Business Rules Management Services | Along the same lines as workflow and knowledge modeling services, rules managers may be simple enough for users or super users to operate, or may be the responsibility of business or systems analysts. This class of services usually expedites the fine-tuning and enhancement cycles so changes to systems need not go through complex and time-consuming development cycles. Advanced workflow, model and rules managers, however, do not eliminate the need for disciplined QA and planning. |
| Semantic Content Association and Search Services | All the services above and all the services below are embodied in relatively mature off-the-shelf systems and open-source tools available today. Tools for semantic modeling and integration in layered systems architectures are not yet as mature, nor are the integration points and patterns consistent from one approach to another. This is a significant barrier for escaping the gravitational pull of information, and entering the outer space of knowledge. |
| Distributed Content Access and Manipulation Services | The distributed part is not essential for all systems, but it's becoming more important every day. Most legacy systems work with a single centralized database: structured mostly atomic data only. Workers' requirements now often include access to more than one database, plus document files, spreadsheets, images, videos, sound files and other rich media. The services in this layer provide authorized requestors access to all the information they need. |
| Interprocess Communication Manager/Monitor | When implemented at a medium to small granularity, a single capability may consist of dozens or hundreds of services. 'Interprocess communication (IPC) is a set of programming interfaces that allow a programmer to coordinate activities among different program processes that can run concurrently in an operating system. This allows a program to handle many user requests at the same time' (TechTarget IPC Definition)." |
| Resource Manager / Shared Resource Config DB | This is a highly advanced layer for managing both structured and unstructured data both in storage and in streams. In addition to managing traditional stored data, this layer may handle one or more continuous data streams, and possibly support long-running continuous queries, expected to produce timely answers continuously. The resource manager may alternatively (or additionally) provide infrastructure management functions. |
| Access Manager / Shared ID & Privilege DB | This layer and its services provide a framework for both knowing what people and systems are permitted to see or manipulate what content, and intelligently controlling access to computer resources, enforcing policies, auditing usage, and providing the information necessary to bill for services. This is the triple-A layer – Authentication, Authorization, and Accounting – and may use open standards like LDAP or commercial tools like Active Directory (AD)." |
| Distributed Content Layer | OK – the content may not be distributed. It may be on a single disk on the same server as the application, and that's OK. Many complex systems, however, require access to lots of data in more than one place. Consequently, this layer may be spread out across the globe and on other planets. This layer supports big data systems like Cassandra and NoSQL, in which content workloads are distributed across multiple clusters and nodes with no single point of failure. |
Enterprise systems often use both atomic (such as relational databases) and unstructured content. Some models place only the data on the back-end hardware and put all the management functions in the middle tier. The clear distinctions in the structure between n-Tiered and DSS (prior post) are the model base and the interactivity of the “Dialog.” Expert systems rely on a rule base and robust interaction with users to achieve their goals.
We can envision a Dialog Generation and Management System (DGMS) as middleware because it can include some of the more complex business services or processing components of the overall system. These components were also described on the prior posts. The next step beyond n-Tiered systems is large-scale hybridization. Every day more companies are beginning to rely on multi-computing systems in heterogeneous networks. I will plan to cover these in a future post.
Do multi-tier architectures resemble the human brain’s layered components or layered neural networks? Perhaps the similarities are few and the resemblance is very tenuous. But layered architectures for complex knowledge systems are nonetheless critical in helping us move toward the age of knowledge.
| Click below to look in each Understanding Context section |
|---|
| Intro | Context | 1 | Brains | 2 | Neurons | 3 | Neural Networks |
| 4 | Perception and Cognition | 5 | Fuzzy Logic | 6 | Language and Dialog | 7 | Cybernetic Models |
| 8 | Apps and Processes | 9 | The End of Code | Glossary | Bibliography |
SHARE THIS ARTICLE
