Moiz Ahmed

November 2007

Summary: This paper endeavors to define a dynamic framework for business management applications development. The framework is based on the concept of business components and groups with a focus on business process implementation. An important goal of the framework is to enable the architects and developers to envision the bigger picture during the application design phase. This will support development of a software architecture that will be cost-effective and easily adaptable.

Contents

Introduction
Dynamic Business Management Application Architecture
Scalability in DBA2
DBA2 Conceptual Implementation for Product Manufacturing Businesses
Conclusion
APPENDIX – A
References
About the Author

For more information and future releases on DBA2 please visit http://www.dba-2.com.

Introduction

Today’s business management applications are data–centric, involving complex back-end processing. Applications built to resolve small-scale, simple business problems may not have all the post-release maintenance and scalability problems associated with complex business issues. GUI applications are mostly event-driven—a change in data, a human interaction, or a business process generates an event that generally triggers a series of events or procedures to fulfill the request made by the initiating element. The computation of these results is again based on the data involved and the initial request. The common factors at this point that an architect looks into are (but not limited to):

• Performance based on data transformation
• Time required to compute results
• Hardware required
• Implementation

In my view, some important factors commonly left out at this stage are ROI, post-release or implementation maintenance (which directly relates to return on investment, or ROI), and scalability (alignment with business growth). Since many businesses depend on technology, this may change the strategic direction for the business to accommodate the costs associated with such factors. In other words, if implemented correctly, these will contribute to align an organization’s technology with its business, strategic, and financial goals.

More importantly, the rapid change in technologies has made it difficult for application developers to find a stable solution to manage post-implementation maintenance and scalability. Many companies struggle with the return on investment envisioned, instead of the actual investment made to manage the business problems that the technology was meant to solve. Along with that come the issues of performance, data transference over intranets and possibly the Internet, graphic user interface alignment with the underlying architecture, and the investment required to constantly update individuals’ skills to keep pace with the technological changes. It is fair to say that the solution may not always lie in the technology; it is probably more in the technical framework underlying the technology, a cross-platform, multi-dimension or multi-process independent module framework that can communicate intelligently among its components as well as externally through a core that can manage the entire application’s events, messages, and change in behaviors based on the events initiated (more on this solution in the following paragraphs). SOA and Web Services brought a major change in the way we think about developing applications, but most technology executives are still struggling with the cost and time associated with maintenance, technology integration, and the cost involved in implementing both. The technology meant to solve business problems has created another dilemma: “Should we spend more money to maintain and scale what we thought would make us money?” Granted, the costs will always be there, but the goal is keeping them to a minimum, knowing well that business leadership often has not been very cooperative in this regard.

As a solution, we can provide architects with a framework, which not only eliminates the need to evaluate many technologies present, but also helps to align the technical goals with business strategic goals and, more importantly, financial goals. In the following paragraphs, I will try to conceptualize such a framework.

Dynamic Business Management Application Architecture

In the world of object-oriented programming, each object has its own life cycle and a relationship to the rest of the application components. What makes DBA2 unique is how much code we put in an object to manage its own tasks and interact with external elements, which is called coding and inheriting intelligence for an object in DBA2. Envision each object as a living being that can be combined to form bigger components for the application, derived from and related to the core components of the application to gain maximum advantage from the two fundamental concepts of object-oriented programming: polymorphism combined with inheritance while seizing the advantages of the encapsulation. Before we get into the details, this concept is intended to achieve the following goals:

• Provide ease in application implementation through independent intelligent modules while retaining:
• • Technical framework integrity
  • Greater performance
  • Maximum code reuse
• Attain straightforward application scalability
• Facilitate software architects and developers in realizing the bigger picture in the pre-development phase
• Achieve greater ROI and customer satisfaction by minimizing post-release maintenance
• Provide a ready-made, conceptual architecture for business management applications
• Minimize development costs and defects while providing speedy time-to-market (TTM)

DBA2 relies on the multiple business components that combine together to create an application. A business component is defined in Appendix A. The building blocks for DBA2 are explained below.

Element

This is the framework’s lowest-level item. All others are formed by combining multiple elements. The top-level element will contain common intelligence functionality to manage internal processes as well as interactions with external items. The top-level element will also have intelligence to interact with the CCS and other system logical groups to facilitate the communication for its descendents. Note here that an element will still be able to maintain its integrity while having reasonable capability to integrate with rest of the application. Integration for each element will depend on the business or functional requirements of the element. An element may consist of one or more objects from an OOP point of view.

Functionally, an element would map to the smallest part of the business process. For example, in a customer management application this may be the customer’s tax management system. An element will have the following characteristics.

• Derived from the customized core object with intelligence to manage all its tasks independently
• Intelligent enough to manage external interactions from other elements, entities, and the Logic Central
• Contain linkages to the core logic groups
• Instantiated in its own thread to maintain its independence
• Able to integrate into the module that will have some of the same characteristics as the object itself

Entity

An entity is the combination of multiple elements as derived from the core entities. A core entity has the functionality leveraged from all its contributing elements’ relationships with the core system entities and digital central nervous system. Each entity is part of a logic group found within a stage in its own business unit. The business units are formed based on the functional commonalities from a business process point of view.

Functionally, an entity will correspond to a business component. For example, in a customer management application an entity may be a combination of all elements that form a customer’s accounting operations, such as orders, taxes, payment information, and the history of all such elements. An entity’s purpose is to encapsulate one or more business processes within a business component in order to create independent components (Business Process and Business Components are Defined in Appendix A). Core entities are a part of the core logic group (CLG) of the digital logic brain (DLB). Along with other characteristics, an entity has the following characteristics:

• Derived from one of the core entities
• Has the intelligence to manage its element integration operations, such as:
• • Communication through CCS (digital central nervous system)
  • Events and relaying of the results for those events
  • Changes in behavior as transmitted by the elements
• While maintaining an individual framework (as stated above), also holds the intelligence to integrate or link its internal elements with external items within an application.
• Relates to component(s) of a business unit from the functional aspect of an application

Figure 1. Elements within an Entity and CCS with Relationships (Click on the picture for a larger image)

Logic Group (LG)

A logic group is a single entity or a combination of multiple entities combined together as they all relate to the same components of a business group. (Business components and business groups are the functional aspects of DBA2 framework and are defined in Appendix A.) Functionally, an LG or multiple LGs in a complex environment will align with a business group. The LGs, like the elements and entities, will be derived from a core LG to use maximum functionalities from the communication control system (CCS) and the Logic Central (LC). A core LG is part of the LC. For implementation purposes, a logic group may reside on one computer or on separate computers. If implemented on separate computers, the CCS can be used to manage the communication mechanism. A DBA2 based framework can have as many core LGs as the business requirements of an application need.  DBA2 in its simplest form will include (but is not limited to) the following core LGs.

• Communication Control System. A CCS is the main LG for messaging and communication in the entire DBA2 framework. This will enable event instantiation and status changes, and will relay behavior change along with data transformation if required. It will also contain an internal authentication logic group that will manage authentication in the case of a client server application system or multiple peer applications. This will also manage the cross-platform application communication system within multiple LGs and applications through APIs, TCP/IP, UDP, or Web services. CCS is discussed in later paragraphs in detail.
• Security Logic Group. This will hold all the elements and entities that manage the common logic for the security and user authentication system. It will be connected with the rest of the logic groups (core, business or any other), entities, and elements through CCS. Security LG will be instantiated through the system LG.
• System Logic Group. The system LG consists of entities or, in a more complex application, LGs that handle the application’s centralized data transformation and any other common operations of the application. For example, a system LG can implement a factory design pattern to instantiate elements, entities, LGs, or even stages. System LG is part of the Logic Central.
• Integration Logic Group. Integration LG will manage flawless integration between elements, entities, LGs, and stages. It is envisioned to be a highly complex structure that will hold the logic to manage updates that result from scalability, modification, and defect fixes, and also enable the application’s integrated operations to function with minimum effort and change in the business, GUI, or any other elements, entities, LGs, or stages.  Integration LG is envisioned to integrate heavily with the CCS and system LG and their internal components.
• External Communication Logic Group. This LG will enable DBA2 framework-based applications to integrate with third-party applications. This will provide an authentication mechanism based on public and private keys or other appropriate authentication security techniques. In a Web-based application, this may be done via implementation of a Web services gateway, and it may be implemented as a middle tier, Web service, or as part of system LG or CCS.

Figure 2. Basic Implementation of Logic (Click on the picture for a larger image)

Stage

Functionally, business components and groups are implemented through LGs. To facilitate the technical framework, a stage is implemented. A combination of LGs with similar technical functionalities will constitute a stage. For example, a stage may combine all the data transformation LGs for an application or implement business processing LGs. Each stage will be derived from or will be a descendent of a core stage. From an implementation point of view, there is no limit to the number of stages in an application, but it is important to note that a well-thought-out implementation for stages would facilitate future enhancements and scalability operations in the application. A stage may still have associations with the system or core LGs to achieve administrative goals for the application. CCS LGs or entities will be used to facilitate inter-stage communication. Because of the operating system’s complex memory management mechanisms, the stages may lose state, behavior, or data after they are carried from one stage to another. To maintain these, a dynamically created stage will have to be updated. One such mechanism can be implemented by saving the elements in memory and updating the subsequent stage from memory. To maintain performance, each stage may be instantiated in its own thread and updated from the communication control system’s common elements that temporarily hold data while it is transferred from one stage to another. Figure 3 shows a simple stage implementation.

Figure 3. Simple Stage Implementation (Click on the picture for a larger image)

Communication Control System (CCS)

A CCS is the main LG for messaging and communication within the DBA2 framework. This enables event instantiation and status changes, and will relay behavior change along with data transformation if required. It will also contain an internal authentication LG that will manage authentication in the case of a client server application system or multiple peer applications. This will also manage the cross-platform application communication system within multiple LGs and applications through APIs, TCP/IP, UDP, or Web services. CCS is the communication backbone of the application framework that will be managed by the Logic Central. It manages the messages sent by different components of the framework, and ensures speedy delivery with reply messages, communication, and status changes at any level of the framework. CCS will have the following main components.

• Event
• Status
• Communication

Each element, entity, or LG will be able to initiate events to corresponding components and receive the same. This will trigger a response by the receiving component and a change in status to match the sender’s request. The change in status will change the component’s behavior, and the application’s overall operations will be carried out in a similar fashion. The communication component of CCS will manage event and message communication with all components contained in the stages and application(s).

Logic Central (LC)

The LC manages all the core elements, core LGs, and core stages for the entire framework. This will be where the main intelligence for the application resides. LC is a complex framework holding all the common procedures, methods, logic, and patterns as well as the core items of the CCS. Every other element, LG, stage, and communication LG will be derived from logical parts of the LC.

Scalability in DBA2

To manage scalability in the DBA2 framework, the elements within an entity are designed logically while keeping the organizational business and process frameworks in mind. If the elements are designed correctly, entities and LGs will fall into place. The greater the numbers of elements, the more complex the LC and CCS will be.

From a business point of view, application scalability or modification supports easy implementation, minimum resources and time for release or TTM, and higher product quality and customer satisfaction. A simple example of how DBA2 can accomplish these goals can be seen by implementing an integration LG. Because of the emphasis on design and understanding its complex nature before coding begins, it ensures that application updates, for scalability or for any other purpose, can be achieved with minimal coding, resources, and time. In this way, it helps to ensure that the post-release technical goals are in line with the organization’s financial and business goals.

One of the goals of DBA2 is to enable software architects and programmers to look at the bigger picture before beginning the coding or development phase of the SDLC. The framework defines (enterprise level) business management application components that will aid the business process translation to technical design for the organization even before the design phase of the application. This will also help align the technical design strategy with the business units or components (defined in Appendix A). If implemented properly, it will help the staff to design an application that can be easily modified or enhanced since the business vision has already been (conceptually) implanted into the design. In version 2.0 of the DBA2 framework, we will attempt to write a process that will enable the architects or software developers to implement the DBA2 to understand and align the functional aspects of the business process with the technical framework before a design is written.

DBA2 Conceptual Implementation for Product Manufacturing Businesses

For purposes of demonstration, a sign company will be considered for a basic DBA2 framework implementation.

Statement of Current Situation

Manufacturing companies currently run the risk of being unable to provide their customer base with a timely status or track progress during the manufacturing phase once an order has been placed. The lack of an automated system to track product manufacture progress, resource management, and task allocation is a problem for manufacturing industry.  The inability to offer timely response to a customer inquiry and a slow turnaround time from inception to finished product is likely to lose customers for the business.

The process of production from order placement to delivery phases for product manufacture in its current manual mode is inefficient in that it involves multiple departments that need to communicate interdepartmentally as well as functioning independently to meet their own deadlines. Additionally, the manual processes cause redundancy, which leads to duplicate resource allocation, additional cost, and scheduling conflicts. The organization’s internal processes do not function within a centralized information base for the product development phases.  An easy method of communication interdepartmentally should exist between departments for tracking progress and task allocation, to facilitate planning and timely delivery of the product as well as customer-driven inquiries. A general overview of the problem may read as follows:

• Organization’s internal processes do not use an automated centralized information base for product development phases.
• Departments need a more cohesive interaction with other related departments for tracking progress and task allocation, to facilitate planning and timely delivery of the product.
• Most of the processes are manual and can be redundant, causing duplicate resource allocation or no allocation at all.

DBA2 Implementation

A finished product goes through different phases of a life cycle before it is delivered. From the DBA2 perspective, the product manufacture phase progress and task/resource allocation generally consists of two separate business processes. The product manufacturing process consists of five major parts:

• Order entry
• Design
• Development or manufacture
• QA
• Shipping

To implement DBA2 for such a business management application, each phase of the product development life cycle can be mapped to an LG as follows:

• Order Entry LG, which will contain the following entities with related elements:
• • Customer entity
  • Customer accounting entity
  • Order entity linked with customer accounting entity and customer entity
  • Order history entity
• Design LG
• Development and Manufacture LG
• QA LG
• Shipping LG
• Task Allocation LG
• Progress Tracking

The default stages defined in DBA2 will hold well for the purposes of this application, with CCS as the communication back bone. With dynamically written LGs, it will be easy for each department to function independently and CCS can implement inter-department communication in the form of inter-LG communication.

CCS can also provide manufacture status based on the LG that the product is held in at a specific time, which will enable progress tracking. A centralized resource pool held in a task allocation LG and an explicit communication of task allocation LG with progress tracking and manufacturing phase LGs will help manage the resource allocation. Again, CCS will facilitate a thorough communication between all of the above mentioned LGs. An intelligent design of core and system LGs will enable easy maintenance and application scalability as the business grows.

Conclusion

This paper endeavors to define a dynamic framework for business management applications development. The framework is based on the concept of business components and groups with a focus on business process implementation. An important goal of the framework is to enable the architects and developers to envision the bigger picture during the application design phase. This will support development of a software architecture that will be cost-effective and easily adaptable. The framework relies upon independent intelligent units integrated together through a common logic system, each with the ability to manage its internal functions as well as react to and take appropriate actions based on interaction with external units. The concept gives great room for technical growth as the business grows with minimum cost, better quality, and on-time delivery. It also recognizes and tries to solve common business problems in the software development world, such as on-time delivery and management of TTM, QA, development costs, and post-release maintenance. This is the first version of the concept and may contain errors; however, appropriate modification and broader research will help produce a more refined concept. More information on DBA2 and future releases can be found at http://www.dba-2.com.

APPENDIX – A

Definitions

• Data transformation
  Data transformation consists of any process that manipulates the data, collecting, combining, splitting or formatting. Data dispersion is the opposite of data collection, during which data is written to a database, a GUI object is updated, or a hardware register is written.
• Business component
  A business component is defined as the lowest-level sub-business process of a business process that can function independently with data transmission managed by a supervising entity. A business component may need input from other business processes to produce results. This input is mapped to an event in DBA2 framework.
• Business group
  A business group is the combination of business components. It relates to a business process in an organization with data flow being managed by multiple entities throughout the business process. A business group can independently manage its internal operations.

References

• Technology Ventures by Richard C. Dorf and Thomas H. Byers
• OPEN – Organic Programming Environment: http://www.codeproject.com/cpp/Organic_Programming.asp
• http://www.w3c.org
• Service Oriented Architecture:
  http://en.wikipedia.org/wiki/Service-oriented_architecture#Other_SOA_Concepts
• IBM – An introduction to web services gateway:
  http://www-128.ibm.com/developerworks/webservices/library/ws-gateway/
• Essential Business Process Management by Michael Havey
• Behzad Karim’s Article on BASL From 6th Issue of Microsoft Architecture Journal: http://www.architecturejournal.net/2006/issue6/Jour6behavioral/default.aspx

About the Author

Moiz Ahmed is a Technical Project Manager for Entessa with 15 years of experience in Software Engineering, Architecture/Design, and Executive Management. Prior to working at Entessa, he managed the development and QA departments as Senior Software Manager/Chief Software Architect, with projects ranging from $50K to $2 million. Moiz’s experience includes Enterprise Application Integration, BizTalk, SOA, strategic business development and alignment between technology and business. His skills focus on developing operationally critical business-management applications to realize ROI with scheduled delivery while maintaining quality and technical product integrity. He has written papers on software maintenance, automated software test planning, and SDLC, A C-Level Perspective. Moiz is also skilled in CMMI, SCM, and Change Management.

Moiz Ahmed is the founder and Founding Chairman for Magic City Technology Council (http://www.bhm-tc.org), a Birmingham, Alabama engineering organization promoting Software Engineering, QA and Technical Project Management. There he managed all aspects including the start-up initiatives, executive committee, board of advisors, strategic and business development, vision, financial, sales, legal, marketing and HR. He is also a member board of advisors for ITT Technical Colleges and Magic City Technology Council. Moiz can be contacted at ahmedmoiz@hotmail.com or (205) 602-1200. For more information and future releases on DBA2 please visit http://www.dba-2.com.