Agile IT Architecture

I just finished a proof of concept for a manufacturing customer on how to use a inference engine to process events coming from a Manufacturing Equipment System. Without breaking any confidential information, I just want to highlight the use cases, the proposed architecture, and give some example of rules. At the high level, the business use cases are real time fault detection and equipment monitoring. Equipments are tools running on the manufacturing floor. The manufacturing tools process parts. After a certain amount of work processed, a tool needs some maintenance and any parts assigned need to be inhibited so the MES can route these Work In Progress parts to equivalent tools. Tool can generate alarms, and the system can take preventive action and/or alert people to avoid bigger problem. So for fault detection a rule looks like: if Alarm_id == 36 then inhibit parts running on tool initiating the alarm, and send email and SMS message to floor manager I have to complete this rule set w

Gartner says the " Number of Organizations Planning to Adopt SOA for the First Time Is Falling Dramatically ". I will summarize the facts as below: 53% of person contacted are using SOA in some part of their organizations 25 % were not using it but had plans to do so in the next 12 months 16 % no plan to use it 20 % are building Event Driven Architecture 20 % are planning to do EDA in the next 12 months Since the beginning of 2008, there has been a dramatic fall in the number of organizations that are planning to adopt SOA for the first time. down to 25 percent from 53 percent in 2007 Many organizations have evaluated SOA and have chosen not to spend time and effort on it The highest concentrations of organizations not pursuing SOA and having no plans to do so are in process manufacturing and agriculture and mining SOA adoption in Europe is nearly universal, moderate in North America and lagging in Asia Main reasons listed are: No clear business case – but there is a great de

I just had a look to the presentation from Sandy Kemsley done at the business rule forum: " Mixing Rules and Proces s" and her blog entry on BPMS and BRMS integration. I can quickly summarize the points she made that I love and share some feedback: Does BPM has Rules? yes but typically not full-features BR. Rule changes may require redeploying processes with IT involvement. Separate rules from process: externalize decision from process. Call BRE from BPE. Benefits from separation: compext rules automate manual process, reuse rule across processes, change rule without processes. In her blog entry "As a BPM bigot, I see rules as just another part of the services layer... but I didn’t hear that from any of the vendors." It may be because ILOG team was not speaking... ;-) We are pushing, saying and we are delivering projects since 4 to 5 years where we have a clear separation between decisions done by business rules from process flow, and designing solution where the bu

Recently I had to re-do some JSR94 code and I'm still interested by this work done some years ago and I'm still supportive of it. But as Roy Johnson was saying recently during one of his presentation "Where will tomorrow's enterprise innovation come from?". Does JSR94 is one of this "unhealthy Java standard" like JDO was? Done in a period where the Java community wanted to standardize everything ? For the recall JSR-94 is an industry standard that defines how Java programs deployed in J2SE or J2EE can acquire and interact with a rule engine. Being able to change engine implementation is a nice design approach, but as of today this specification is limited by the fact that there is still no standard to exchange rule definition between engines. So rule written for one engine can not be used by another one. This dramatic limitation is undermining the use of JSR94. And i'm still surprise to see architect asking compliance to it. Although the horizon is

I spent two days last week to study the Semantics of Business Vocabulary and business Rule or SBVR specification. SBVR is part of the OMG’s Model Driven Architecture (MDA) with the goal to capture specifications in natural language and represent them in formal logic so they can be machine-processed. It includes two specialized vocabularies: * Vocabulary for Describing Business Vocabularies which deals with all kinds of terms and meanings. * Vocabulary for Describing Business Rules which deals with the specification of the meaning of business rules, and builds on top of the previous vocabulary. The meanings are declined into concepts, questions and propositions. The meaning is what someone intends to express or understands. A phrase such as "We deny the invoice if the medical treatment was done after one year of the accident" has a clear meaning for a claim processor within a car insurance company. Analysts need to transform logically this meaning into concepts which has

AAAAAH. Today I discovered a very nice implementation of business rules done by HP. At home I have a HP photosmart 8250 printer who today displayed the message:"the ink cartridges are past its expiration date!" So each ink cartridge has a date and the code in the printer is testing this business rule to force me to buy new cartridges.... It is not enough to get printer drinking cartridge ink like we drink water under 100F, but in case we are not printing enough, this rule enforces business. Sad commercial behavior, bad rule, I'm just now hoping they are using a rule engine so I can change the rule on a fly... A dream.

During one of my last web seminar I presented, I got the following question, I want to share the answer on the blog: " How much IT involvement would be necessary for making rule changes, assuming that the business person can change the rule and test it on their own? " IT is always responsible of the production platform. As such it is controlling the quality of the rules deployed to the servers. As the simplest process you can have the business users maintaining the rules within the web based BRMS component and even deploy to a test server to do some simulation testing and what-if analysis. Once the rule execution set is ready for deployment to production, IT can create baseline, extract the rule set from the rule repository and then apply some non-regression testing suite to verify that the rules are still working as expected. This is a good timing also to verify that any changes done at the data model level (logical or physical models) are not impacting existing rules. T

I spent the last four months to dig into Complex Event Processing offerings and especially how BRMS and CEP can work together to support new type of business applications, and to move to agile IT architecture. As stated by Professor David Luckham in his book the ‘Power of events’: future applications need to address the following problems Monitor events at every level of the IT systems Detect complex patterns of events, consisting of events that are widely distributed in time and location of occurrence Trace causal relationship between events in real time. Take appropriate action when patterns of events are detected. Adding CEP engine within our IT architecture will help bring agility as we can define complex patterns of events, hot deploy them, execute them, and improve their scope by time. CEP solution today uses a language close to SQL to define statement which filters, aggregates, joins events, and applies pattern matching on stream of events. Those stateme

I will try to do some specific rule analysis to illustrate some of the ABRD concepts. ABRD proposes to do the analysis activities as soon as possible and in parallel of the rule discovery, this helps to identify the issues, gaps, and clarify the rules under scope. So let imagine a claim processing application for a car accident. There are some injured persons who reported the accident claim and with some medical providers who send medical bills to the insurance company. One important step of the rule discovery is to clearly understand the business process. For this example we can outline the basic process for claim processing looks like the following diagram: In brown the decision points that are rule rich, so will be mapped to a rule set. Taking one rule from the adjudication decision point we will build a domain model: “ Ask for an expert audit if one of the treatments includes an emergency room treatment or an ambulance transfer done on a day after the accident. “ Claims a

Hi Thank to all of you to attempt my last web seminars on ABRD, SOA, and Effective rules writing. You were around 850 to register and close to 400 to attempt. This is showing an interest in best practices around business rules and their implementation. Feel free to ask me more questions by email, and I will start to respond on this blog and on the isis blog to the more common questions.

Well I did not post since a while. I was working on an interesting subject related to Complex Event Processing. I will detail that in close future. In the mean time coming back to our purchase Order sample, I will take the architect's hat, and outline the deployment of BRMS within a SOA approach. SOA has proven to be a great technology to make enterprises more agile. With their ability to separate business logic from its implementation, BRMS adds more capabilities to the SOA. SOA is a progressive architectural style for creating and using business tasks that are packaged as services. The main goal of these services is to expose loose coupled business functions to facilitate deployment, combination, and reuse within different applications. SOA supports the integration of heterogeneous systems, as soon as they are exposed over the internet using standard protocols like HTTP, XML, unified interface definition (WSDL). Every business has rules, and business users want complete control

There are a lot of requests from colleagues, customers, readers of ABRD to get a sample covering the main activities of ABRD from A to Z. I'm working on a book with a friend of me, which will cover all the ABRD activities in detail, and provide detailed samples. But for the moment I will take a simple purchase order process. There are a lot of samples on the web around this process, but here I'm focusing on a simple version of it. This Order Process may betypical B2B scenario, in which multiple stateful services interact with each other. Two sources for the order request: one online with an Internet customer submitting an order on a Web page, and one using an automatic purchase order issued by a well known authenticated customer-partner. In ABRD using a business process centric approach for discovery – analysis – implementation we start by doing the analysis of the process, then we go to the data modeling, rule harvesting, and service design in parallel like the following dia

Hi Thanks a lot, to all the attendees on last week web seminar , we got records of registered persons and connected ones. There are a lot of questions, and I could not respond to all of them. So I will use the BLOG to answer the questions related to Agile Business Rule Development and other architecture discussions. For Europe we plan to do a second webseminar, I will announce it.

Today I would like to present a very nice article in a IT french journal “ Solutions logiciels ”. This is related to sustainable architecture . I’m working with Pierre Bonnet, the author of this article, on this matter, and try to share experiences on BRMS, as one of the corner stones of the Agility Chain Management System , I will try to summarize the main points of this article in french as it is relevant over the world: The IT infrastructure in a lot of companies suffers from a lack of investment to modernize the legacy, which adds complexity when development team deploys new applications. Business and IT managers are focusing in short term ROI putting on hold long term investments needed to build a long term sustainable architecture. Added to these, we can foreseen three layers of IT staff: the senior with their knowledge of the current legacy systems and the business requirements, the intermediate layer with people skilled in client/server and EAI technologies, and the yo

Make Developing Business Rule Applications Easier What: 60-minute best practices webinar When: Wednesday, May 7 Who should attend: Architects, developers, application programmers, software engineers, IT senior managers, IT team leaders, and anybody who wants to learn more about developing business-rule applications Learn about a rules-specific methodology designed for short turnaround times: Agile Business Rule Development (ABRD) When you're building business rule applications, generic software-development methodologies just aren't enough. Agile Business Rule Development (ABRD) is a step-by-step process for developing business rule applications. An iterative methodology, ABRD employs agile software-development values. Rule development is organized as a series of cycles: discovery, analysis, authoring, validation, and deployment. Your team stays on schedule, deli

The purpose of this article is to present an integrated software life cycle for development team who wants to leverage the capabilities offered by technologies such as BPM-BPEL and Business rules management system. Each new business application development is triggered by a business needs to support or enhance and improve business efficiency. Even with an Agile approach, to trigger the project, architect, business users, project manager and project sponsor have to work together during the Inception phase, to define the business case, the requirements and justifications of the project. Once the project funded, the team may work on specification and requirement documents. I simplify a little here because in reality a lot more documents may be produced, but the goal here is to present how those requirements are supported in an Agile way using the BRMS and BPM products and not discussing about requirements management. So let state the specifications are our main entry point to detail the m

Yesterday ILOG Inc announced his donation of his Rule Based Methodology to Eclipse Consortium. I need to provide some explanations on what this donation is about. The Agile Business Rules Development methodology (ABRD) is the industry’s first free, vendor-neutral methodology delivered as an Eclipse Process Framework (EPF)OpenUp plug-in. ABRD provides a step-by-step process for developing business applications using technologies such as Business Rule Management System, BPM, BPEL. ABRD mitigates the risk associated with new business rules initiatives by providing a well documented and structured approach for developing rule-based applications. ABRD allows organizations to avoid using ad-hoc processes or having to expend significant time and effort creating their own best practices. In case you never have a look at EPF, Eclipse Process Framework provides tools for software process engineering to develop methodology. It comes with content knowledge organized in library, and with a tool, E

Eclipse Process Framework just integrated the Agile Business Rule Development plugin into the OpenUp library. This abrd_openup plugin addresses the development of business application using rule engine technology and Business Rule Management System. This is pre-release 1.0 but it already integrates a lot of content around rule discovery and analysis. I am working on the architecture track and will be able to deliver a new version in March. So any comments or contributions are welcome. Please download EPF and the OpenUp library and let me know your thoughts.

The Agile Business Rule Development methodology details all the different activities to develop a rule set, from rule discovery to rule set deployment and maintenance. We can group the set of activities into five groups. Those groups will be used to build an iterative approach to the development: Rule Discovery Rule Analysis Rule Authoring Rule Validation Rule Deployment The following diagram represents how the five groups of activities can be executed in a process flow using loops to implement short iterations. The rule set will grow following these cycles to get closer to the outcome expected by the business. Figure 1 Rule Set Development Life Cycle In the first loop, between Discovery and Analysis, the team harvests the rules from the business process description, the subject matter expert knowledge, legal documentation, use cases or any other source. This loop represents the first phase of the rule set construction. 1.1.1 Cycle 1: Harvesting This phase is lim