Sunday, August 18, 2013

Where to Capture Business Logic

The main responsibility of enterprise architects is to have a holistic picture of Business Logic of the whole enterprise, mostly not in the level of part of the organization.


Business logic, or domain logic, is a non-technical term generally used to describe the functional algorithms that handle information exchange between a database and a user interface.

More generally speaking: "Business logic" is a blanket term that covers several very different types of stuff -- at a minimum, algorithms, business rules, workflows, and integration logic. As a general rule, algorithms belong in object libraries, business rules in a BRMS, and workflows in a business process management system (BPM).




1. Three Levels of Business Logic 

Business Logic can be divided at three levels 

Strategic: In a Strategic Architecture EA decides on High-Level Capabilities inside the organization and consider the interoperability concerns (Business Logic) how the end customer will be served to utilize these capabilities; At Strategic level, business logic is nothing but Business Model to make profit.

• Segment: At the segment level, EA considers the individual Business Units inside the organizations and it further considers Business Processes supporting the end capabilities and we can call them business functions and we devise business rules supporting business processes. Architecture at segment level supports Strategic level capabilities. At segment level (Program and Portfolio Level), business logic supports business functions (Business, Data, Application, Technology).

Capability: At the capability level, EA considers the actual implementation of capabilities where environment, technology, applications, databases come into the picture that is generating a capability to support Segment and Strategic Level. EA considers capability increments based on developed business logic. This comprises of Application capabilities, logical data models, Infrastructure to support Business functions that further support Business Services at a strategic level. At the capability level, EA considers interoperability concerns for Solution Architectures using business logic. 

2. Three Views of Business Logic 

Business logic comprises business rules that express business policy (such as channels, location, logistics, prices, and products); and workflows that are the ordered tasks of passing documents or data from one participant (a person or a software system) to another. Business logic, comes in three, partly overlapping views.

  • Information. EA looks to see if enough information is coming in and going out. Very importantly, EA checks to see if the information is in or out of balance and whether it is sufficient for optimized operation and also what informational investments you have that will support operation and growth. 
  • Rules: The business rule is a rule of a business, company, or corporation. It is a rule that defines or constrains some aspect of business and always resolves to either true or false. Business rules are intended to assert business structure or to control or influence the behavior of the business. Business rules describe the operations, definitions, and constraints that apply to an organization. Business rules can apply to people, processes, corporate behavior, and computing systems in an organization, and are put in place to help the organization achieve its goals. Business logic should distinguish between:
    * Decision rules: entail the responsibility of human agents, architectural footprint.
    * Constraints and computation rules: can be fully supported, with no architectural footprint.
    * Control rules: can be fully supported, architectural footprint. 
  • Objects. Usually only the information and rules are supported by tools, while the object is the most powerful and flexible view, and can provide models for the business information and business rules. 

3. Integration Logic 

At the segment or capability level of business logic, integration logic tends to be the thorniest, as this is where semantic mismatches between systems come into play. Business logic usually does not come into play at the strategic level at all. The actual business logic is a bit too detailed in nature to be addressed at a strategic level. It starts to come into play at the operational level but the real detailed business logic tends to get captured in solution architecture models.

The main responsibility of enterprise architects is to have a holistic picture of Business Logic of the whole enterprise, mostly not in the level of part of the organization. Without that whole picture, separate parts of the organization will care for their own part and maybe for interfaces and not more. If the logic is clear enough, it can be captured and automated via coding, within process logic, there's data logic, application logic., etc. Integration logic needs to be captured to ensure the organization as a whole is superior to the sum of pieces. 







0 comments:

Post a Comment