Business Process Management (BPM) und Business Rules Management (BRM) zusammen in einer service-orientierten Architektur (SOA) sind die methodischen und technischen Voraussetzungen, um Geschäftsprozesse zu industrialisieren und agil zu sein. BPM schafft die Automatisierung und Standardisierung von Geschäftsprozessen, BRM die Standardisierung und Transparenz von Management-Politiken und -Prinzipien. Und eine SOA bringt die Service-Orientierung, die uns erlaubt zwischen spezifischen Logiken einzelner Prozesse und prozessübergreifenden Logiken gebündelter Kompetenzen und Dienstleistungen sauber zu trennen. Das schafft Agilität zusammen mit Industrialisierung.
Most BREs today are deployed as “decision services”, and are used in “stateless” transactions to make “decisions” as a part of a business process. A CEP application is instead processing multiple event streams and sources over time, which requires a “stateful” rule service optimized for long running. This is an important distinction, as a stateful BRE for long-running processes needs to have failover support - the ability to cache its working memory for application restarting or distribution. And of course long-running processes need to be very particular over issues like memory handling - no memory leaks allowed!
TOGAF 9 encompasses the entire enterprise architecture life cycle, which is important as architecture is a never ending journey, always changing and evolving. The figure below depicts the TOGAF Architecture Development Method (ADM) which covers the entire architecture life cycle.
Rob sees three key areas where rules can help:
Tighter warranty controls
Claims processing is improved because financial limits, detailed coverage types, materials return and more can be automated and rapidly changed when necessary. The rules also allow “what-if” testing and impact analysis.
Better built vehicles
The decision making is tracked very closely thanks to rules so you can analyze specific repair types, specific VINs and so on. More effective parts return and generally better information also contribute.
Lower cost repairs
Rules allow goodwill repairs, labor-only repairs and specific kinds of repairs to be managed very precisely. Rules-driven decisioning can reduce the variation of costs between dealers and help intervene, rejecting or editing claims that seem overly expensive. The ability of rules to deploy data mining and predictive analytics can also really help here.
The Zachman Framework is a framework for enterprise architecture, which provides a formal and highly structured way of viewing and defining an enterprise.
The Framework in practice is used for organizing enterprise architectural "artifacts" in a way that takes into account both:
who the artifact targets for example, business owner and builder, and
what particular issue for example, data and functionality is being addressed.
These artifacts may include design documents, specifications, and models.[3]
The Framework is in essence a matrix,[4]. It is named after its creator John Zachman, who first developed the concept in the 1980s at IBM. It has been updated several times ever since.[5]
The objective of this document(*)
is to provide some rational, structured access to an analysis of cognitive and agent architectures (for
more information on accessing the document, see the Reader's Guide). Twelve architectures have
been used for this preliminary analysis representing a wide range of
current architectures in artificial
intelligence (AI). The aim of the project is to facilitate both
an understanding of current architectures and provide insight to the
development of future, improved intelligent agent architectures.
This work was based on publications from 1992 and before and has not
been authorized by the researchers responsible for particular
architectures (see DISCLAIMER for additional
information).
at the core, enterprise architecture is very simple: it starts with the idea that one should plan technology purchases and development ahead of time and -- here's the important part -- that the business people, not technology people, should determine what is needed (the requirements).
For those unfamiliar with business-driven architecture, I believe the most viable, agile architectures will be comprised of a blend of architecture strategies, including (but not limited to) service-oriented architecture, event-driven architecture, process-based architecture, federated information, enterprise integration and open source adoption.
As the link between business and IT strategy, the enterprise architecture outlines the framework for IT solutions. The EA describes IT structures, standards, processes and shared corporate services. The task of an EA is to support the business areas and IT experts in shared planning processes and in the comprehensive further development of the IT architecture. Detecon decided to use TOGAF from Open Group as an open and widely accepted standard as basis for our architecture work. A comprehensive experience from successful projects at customers with different size and industry demonstrates the benefits of that strong methodology. Based on TOGAF basic structures, Detecon enhanced the methodology in different areas, e.g. the finance and controlling, business cases, governance or SOA migration strategy, and applies those successfully.
Detecon trains architects in the TOGAF framework with the following goals:
To accelerate architecture development at their companies
To reduce complexity in planning heterogeneous best-of-breed systems
To secure the implementation of all requirements
To ensure security for the future
To provide a tool for improved communication of goals and strategies for business units and managers.
On Event Processing Agents implies a “new” event processing reference architecture with terms like,
(1) simple event processing agents for filtering and routing,
(2) mediated event processing agents for event enrichment, transformation, validation,
(3) complex event processing agents for pattern detection, and
(4) intelligent event processing agents for prediction, decisions.
Frankly, while I generally agree with the concepts, I think the terms in On Event Processing Agents tend to add to the confusion because these concepts in On Event Processing Agents are following, almost exactly, the same reference architecture (and terms) for MSDF, illustrated again below to aid the reader.
One common problem I see in the IT industry is the qualification of IT decisions. I talk to architects from all around the world and hear a lot of creative and innovate ways of solving problems. More often than not, what I don’t hear is more concerning. When I have asked: Why did we approach the problem in this manner? How does this align to the business? Does this fulfill the business, functional and non-functional requirements Why is this the optimal architecture? Obviously there are a lot of other questions, but to keep this concise above are some sample questions. The last question is particularly interesting. I have heard a broad range of fluffy answers such as: “trust me, I know what I am doing”, “I have been doing this for 20 years, I know how to do this”, “I am the expert of [X]”. All of these responses may be completely true but doesn’t quantify the solution. It doesn’t demonstrate that there was a process or a clear level of due diligence that was performed.
T. Bucher, R. Fischer, S. Kurpjuweit, and R. Winter. Enterprise Distributed Object Computing Conference Workshops, 2006. EDOCW '06. 10th IEEE International, (October 2006)
M. LeMay, R. Nelli, G. Gross, and C. Gunter. HICSS '08: Proceedings of the Proceedings of the 41st Annual Hawaii International Conference on System Sciences, page 174. Washington, DC, USA, IEEE Computer Society, (2008)
A. Harter, A. Hopper, P. Steggles, A. Ward, and P. Webster. MobiCom '99: Proceedings of the 5th annual ACM/IEEE international conference on Mobile computing and networking, page 59--68. New York, NY, USA, ACM, (1999)
T. Nguyen, J. Schiefer, and A. Tjoa. DOLAP '05: Proceedings of the 8th ACM international workshop on Data warehousing and OLAP, page 77--86. New York, NY, USA, ACM, (2005)
B. Schilit, N. Adams, and R. Want. In Proceedings of the Workshop on Mobile Computing Systems and Applications, page 85--90. IEEE Computer Society, (1994)