Why a Business Architecture?

The main goal of a Business Architecture is to enable the business to improve customer service quality through a better transparency, flexibility and adaptability of business operations. The market environment changes more rapidly and the use of technology by customers dramatically influences how a business can operate. Financial services calculation processes, marketing programs, business rules and content change already weekly rather than monthly.

However, if a business architecture has to be modelled, encoded and assembled by using a large number of tools and software components it cannot provide the benefits. Today’s heavily fragmented and hardcoding-integrated IT systems (including SOA) are too rigid to enable rapidly changing business environments. Most IT departments do not focus on adaptability and innovation because they have been requested to focus on lowering cost and system stability. Therefore, six month rollout cycles are the norm with three month being the exception. Business users expectations of stability and executive demands for lower cost are incompatible with the ability to achieve a flexble and adaptive, competitive IT infrastructure. Efficiency is still the main IT goal, with effectiveness a far-off second and agility being no more than an overused buzzword.

Combine this with the misconception that running a business can be pre-planned and therefore encoded into processes and rules, with decisions being taken by predictive analysis based on historical (or better outdated?) business data. I propose that good business decisions are always taken by experienced people who use intuition to combine relevant data in business context. After billions of IT investments neither process management nor business intelligence have delivered the promised wonderland of the automated enterprise that the board can run remotely from the beach. Why?

Neither BPM nor BI consider the human side of running a business and therefore fail to produce a nimble, agile organization. Based on unproven management theories and over-optimistic information technology benefit claims a huge IT bureaucracy is now necessary to manage a complex technology stack. Control and use of the technology stack is only feasable through outsourcing partners and the necessary complex contracts reduce corporate agility even more. Billions are spent by the IT monopolists for marketing to sell an illusion of the IT-controlled business that does not exist and is not achievable by the proposed complex means.

The above situation was the reason for ISIS Papyrus to develop a new IT platform that does not require a huge technology stack and does not need complex programming but a simple modeling and rule definition methodology to build a flexible and adaptible Business Architecture that is mostly under the control of the business and not the IT department.

Agility AND innovation happen on the people level. BPM and SixSigma trash out the people empowerment slogan but fail to deliver because in neither approach people are given the freedom to do things as they see fit as long as the goals are achieved. Enterprise 2.0 is a countermovement to the bureaucratic IT-Governance approach, but if it is simply putting Web 2.0 behind the firewall without giving the user access to plausible business data entities there is not such thing as empowerment.

William of Ockham wrote in Numquam ponenda est pluralitas sine necessitate: “The explanation of any phenomenon should make as few assumptions as possible and not invent further entities to explain a theory.” He was a friar and felt that the one entity of God would explain everything. Bertrand Russel translated it to: “The simplest explanation is usually the best.” Translated further to IT means that coded software systems or process solutions that require substantial resources to be model a business and even more to then adapt it to changing needs make things more complex than necessary. Flexibility AND adaptability by the user – while ensuring transparency and maintainability – are the key capabilities of modern systems. SixSigma adds a lot of bureaucratic complexity that is certainly not in line with Occam’s Razor. Let’s simplify …

A detailed description of Business Architecture features of the Papyrus Platform you will on my Papyrus Architecture blog.

Creating A Business Architecture

Many – including me – evangelize on the noble goal of creating a Enterprise Architecture before setting out on an IT project. One of the key issues with that is that the ‘Enterprise’ hardly ever acts as such. The typical enterprise is at best a federation of little fiefdoms, that more often than not are in constant political warfare against each other. That gets even worse when the enterprise has been assembled by acquisition and worst with hostile takeovers. It is highly unlikely that these fiefdom chiefs will be too happy to collaborate with other chiefs on creating a new Enterprise Architecture. Even if there is c-level buy-in and a champion has been chosen, bureaucratic resistance makes many projects falter. I am quite certain that one reason is wrong expectations set by over-hyped marketing.

Several BPM and application vendors promote the benefits of model-driven development and some even claim that they make that available to the business user (fiefdom chief). Some BPM vendors want the business user to work with a flowcharting tool and others with a requirements wiki/blog thing. This amazing business user would then ‘model’ the necessary business entities. I am sure that comes natural for most, right? This ‘ExtremlySMART’ process software would then generate the process CODE to execute those models. I have to admit that I am in awe. Supposedly that functionality – as simple as described here – ensures a dynamic enterprise with the agility to handle rapid change. Hmm? The user not only can create enterprise models and deploy them automatically but can foresee the necessary changes and how those will impact the current generated code? Amazing. A few abstract models supposedly do the trick. Astonishing. In less than three month those users make it all happen? Wow!

We propose to make much simpler features than architecture models available to business users and more often than not that fails quite miserably. So our software must be less good than our competition? I think not, it is just our marketing that is less blunt. Business users aren’t architects. They do not care about architecture. Just defining what processes one business unit needs and to get them tested takes certainly already longer than three months! Without architectural considerations. No implementation yet. Certainly not the final thing.

But I agree that the reuse and sharing of conceptual business knowledge would be the only chance to properly sell the benefits of a business architecture to business users. It has to be made visible and usable and allow them to not only participate but utilize the existing models to speed up their own implementation and deployment. Business users think in business terms, in content and what they see. Some may even think in rules. Finito. Thats as far architecture will go.

The benefits of creating a consolidated process and content driven architecture are:

Create a reusable business architecture by doing local projects that are managed in a repository Grow the applications by involving business users iteratively within the project to define content, views and processes (not models!) Utilize version controlled change management to deploy the architecture models into a scalable production environment Processes are not rigid flows that require analysis effort but are assembled by users and controlled by rules and trained patterns Enable business users to enter simple natural language business rules

For the business user the application has to look different than to the architect. It has to start with the business organization that represents effectively the role/policy definition for the actual process authorization. Data entities must be real-word plausible things that a business person can make sense of – a so called business object. Not SOA/XML data structures for the service interface. Certainly not BPMN or BPEL. The connection of the service interface to the business object (with or without SOA) must happen once by an IT expert to be reused all across the enterprise given the right authorization.

The next element to be created by business is the business content. Not documentation or descriptive text, but documents that contain relevant business data and information. There is no content without process and process without content you don’t need. (Here I go again …) Based on their authorization business users can assemble and create new business content from a library of texts and logic building blocks. These are linked to task/activity/todo and stored in a business library of processes.

To be able to work with the content the users have to be able to define their processes/cases. I propose (as you know) that there should not be any rigid processes. Users simply drag and drop content and business objects into the case. The process is owned and created by the relevant business users. Creating content outside the context of a business case/process should ideally be impossible.

Now, how can the process/case be controlled and propagated? I propose further that if you start with the right user role/policy authorization and your content is assigned the right role/policy definition for its executable methods, then many complex process definitions fall by the wayside. If only one user role is authorized to change the case state then no further business rules or decision blocks are necessary. But obviously it is possible that a fairly complex rule has to be added that controls what can or can not be done. In this case the business user or analyst can add business rules to the case model, ideally in a non-technical manner. Rules that are linked into the context of the business process are connected to it by events that trace the relationships and therefore complex resolution algorithms such as RETE are not required.

The first level of task assignment should be by role authorization and queue visibility.
If one or more users or departments share the same role assignments then automatic load balancing must take over (load, availability, priority). Rather than coding complex decision trees, decision maps, and decision tables the training if decision patterns is more efficient.
Simple time controlled state changes can ensure that service level agreements are adhered to in the process. Event listeners can trigger rules and rules can send events to interconnect object attribute value changes Rules can not only be simple IF/THEN statements but also commands and object-relational queries and searches. The context of the rule in the process and its event linkage avoids the need for conventional forward or backward chaining. Process state can simply decide whether a process requires human interaction or can run in lights-out mode. (aka straight-through processing).

Let’s  not forget that each user likes his own very special way how the workload should be presented to him/her. I suggest that the users should be allowed and enabled to freely customize their own user interface to their liking. With your typical forms, Java or Ajax interfaces that is not feasible or maintainable.

Last but not least: would it not be nice if the system could discover by itself what summary content state will drive the process state forward. I propose that this has to be the future.

Yes, we can and we should strive to empower the business user. But it has to be more than a marketing announcement. Those you will find predominantely in the BPM community. From giving away flowchart design tools to business users, to requirement wikis there are many so-called revolutionary ideas that at best are incremental progress if at all. The revolutionary ideas are found in the Papyrus Platform.

A Web Services-enabled marketplace architecture for negotiation process management

Product Description
This digital document is a journal article from Decision Support Systems, published by Elsevier in 2005. The article is delivered in HTML format and is available in your Amazon.com Media Library immediately after purchase. You can view it with any web browser.

Description:
As the eBusiness environment becomes more pervasive and dynamic, negotiations between companies are required more frequently than ever. Despite its potential value and the progress in research, the adoption of negotiation systems has been slow in practice. We believe one reason for this is insufficient consideration of process management aspects such as process design, description, and deployment. Business negotiations must be approached from the process management perspective since they take place in the context of corporate processes such as procurement or sales. In this paper, we study system support and automation of business-to-business (B2B) negotiations from the process management perspective. We propose a Web Services-enabled marketplace architecture for negotiation process management and refine it by adding pattern-based process composition. We validate the concept by implementing the proposed architecture using BPEL4WS and evaluating it from various perspectives.

A Web Services-enabled marketplace architecture for negotiation process management

SOA Cookbook: Master SOA process architecture, modeling, and simulation in BPEL, TIBCO’s BusinessWorks, and BEA’s Weblogic Integration

Product Description
In Detail

SOA Cookbook covers process-oriented SOA. BPEL is the best-known language in this area, and this book presents numerous BPEL examples. It also studies proprietary vendor process languages such as TIBCO’s BusinessWorks and BEA’s Weblogic Integration. If you are building SOA processes in the field, chances are you are using one of the languages discussed in SOA Cookbook. The book assumes that the reader is comfortable with XML and web services.

Author Michael Havey works with SOA in the field for TIBCO (and previously for IBM, BEA, and Chordiant). SOA Cookbook is Michael’s second book. Essential Business Process Modeling, his first book, was published in 2005.

What you will learn from this book?

• Document a process-based SOA architecture using “enhanced 4+1″, ARIS, SCA, UML, and BPMN
• Learn by example how to separate BPM and SOA processes
• Model choreography and orchestration in BPMN and BPEL
• Divide a process that involves both manual and automated activities between BPM and SOA
• Manage state in short- and long-running processes
• Model processes intelligently using three variants of a structured “flat form” approach: event-based, state-based, and flow-based
• Develop dynamic processes to manage the “change problem”: problems that arise when you need to change the definition of a process that has live cases in production
• Simulate SOA processes using concepts from discrete event simulation and the Poisson process
• Measure the complexity of SOA processes

Approach

As a cookbook, this book can be regarded as a set of gourmet recipes for SOA. Each of the eight chapters that follow the introductory chapter covers an important concept in process-based SOA and teaches techniques to build solutions based on the concept. Working examples are developed in BPEL, TIBCO’s BusinessWorks and BEA’s Weblogic Integration.

Who this book is written for?

The book is intended for hands-on SOA architects, designers, and developers who want to learn techniques in process orchestration. Many of these readers use, or will soon start using, languages such as BPEL, TIBCO’s BusinessWorks, or BEA’s Weblogic Integration in their projects.

This intermediate-level book assumes that the reader is comfortable reading XML and knows the basic concepts of web services. The book presents several BPEL and BPMN examples, but it explains specific language constructs on the fly; the reader need not have background in these languages.

SOA Cookbook: Master SOA process architecture, modeling, and simulation in BPEL, TIBCO’s BusinessWorks, and BEA’s Weblogic Integration

Web Services Platform Architecture: SOAP, WSDL, WS-Policy, WS-Addressing, WS-BPEL, WS-Reliable Messaging, and More

• ISBN13: 9780131488748
• Condition: USED – VERY GOOD
• Notes:

Product Description
“Other books claim to present the complete Web services platform architecture, but this is the first one I’ve seen that really does. The authors have been intimately involved in the creation of the architecture. Who better to write this book?” –Anne Thomas Manes, Vice President and Research Director, Burton Group “This is a very important book, providing a lot of technical detail and background that very few (if any) other books will be able to provide. The list of authors includes some of the top experts in the various specifications covered, and they have done an excellent job explaining the background motivation for and pertinent details of each specification. The benefit of their perspectives and collective expertise alone make the book worth reading.” –Eric Newcomer, CTO, IONA Technologies “Most Web services books barely cover the basics, but this book informs practitioners of the “real-world” Web services aspects that they need to know to build real applications. The authors are well-known technical leaders in the Web services community and they helped write the Web services specifications covered in this book.Anyone who wants to do serious Web services development should read this book. ” –Steve Vinoski, Chief Engineer, Product Innovation, IONA Technologies “There aren’t many books that are as ambitious as this one is. The most notable distinguishing factor of this book is that the authors have tried to pair down the specifications for the user and rather than focusing on competing specifications, they focus on complementary ones. Nearly every chapter provides a business justification and need for each feature discussed in the Web services stack. I would recommend this book to developers, integrators, and architects.” –Daniel Edgar, Systems Architect, Portland General Electric “Rarely does a project arrive with such a list of qualified and talented authors. The subject matter is timely and significant to the industry.” –Eric Newcomer, author of Understanding SOA with Web Services and Understanding Web Services and Chief Technology officer, IONA The Insider’s Guide to Building Breakthrough Services with Today’sNew Web Services Platform Using today’s new Web services platform, you can build services that are secure, reliable, efficient at handling transactions, and well suited to your evolving service-oriented architecture. What’s more, you can do all that without compromising the simplicity or interoperability that made Web services so attractive. Now, for the first time, the experts who helped define and architect this platform show you exactly how to make the most of it. Unlike other books, Web Services Platform Architecture covers the entire platform. The authors illuminate every specification that’s ready for practical use, covering messaging, metadata, security, discovery, quality of service, business-process modeling, and more. Drawing on realistic examples and case studies, they present a powerfully coherent view of how all these specifications fit together–and how to combine them to solve real-world problems.* Service orientation: Clarifying the business and technical value propositions * Web services messaging framework: Using SOAP and WS-Addressing to deliver Web services messages * WSDL: Documenting messages and supporting diverse message interactions * WS-Policy: Building services that specify their requirements and capabilities, and how to interface with them * UDDI: Aggregating metadata and making it easily available * WS-MetadataExchange: Bootstrapping efficient, customized communication between Web services * WS-Reliable Messaging: Ensuring message delivery across unreliable networks * Transactions: Defining reliable interactions with WS-Coordination, WS-AtomicTransaction, and WS-BusinessActivity * Security: Understanding the roles of WS-Security, WS-Trust, WS-SecureConversation, and WS-Federation * BPEL: Modeling and executing business processes as service compositions Web Services Platform Architecture gives you an insider’s view of the platform that will change the way you deliver applications. Whether you’re an architect, developer, technical manager, or consultant, you’ll find it indispensable.Sanjiva Weerawarana, research staff member for the component systems group at IBM Research, helps define and coordinate IBM’s Web services technical strategy and activities. A member of the Apache Software Foundation, he contributed to many specifications including the SOAP 1.1 and WSDL 1.1 specifications and built their first implementations. Francisco Curbera, IBM research staff member and component systems group manager, coauthored BPEL4WS, WS-Addressing, and other specifications. He represents IBM on the BPEL and Web Services Addressing working groups. Frank Leymann directs the Institute of Architecture of Application Systems at the University of Stuttgart. As an IBM distinguished engineer, he helped architect IBM’s middleware stack and define IBM’s On Demand Computing strategy. IBM Fellow Tony Storey has helped lead the development of many of IBM’s middleware, Web services, and grid computing products. IBM Fellow Donald F. Ferguson is chief architect and technical lead for IBM Software Group, and chairs IBM’s SWG Architecture Board. A(c) Copyright Pearson Education. All rights reserved.

Web Services Platform Architecture: SOAP, WSDL, WS-Policy, WS-Addressing, WS-BPEL, WS-Reliable Messaging, and More

Next Page »