The following are some of the governing principles that must be enforced during a B2B integration project. These points indirectly affect the development methodology and non-functional requirements. Some of the principles described are applicable to the software architecture in general. However, these are described here in the B2Bi (Business-to-Business integration) architecture context. In general, B2Bi means, information exchange with trading partners without a web interface.
• Keep components as loosely coupled as possible: This rule is applicable to all modern software application development. In B2Bi, this rule has special importance as some of the components of the enterprise may be indirectly exposed to the external trading partners. A new component may seamlessly be added or an unused component may be removed without affecting the entire application. The loose coupling can be achieved at component level or at message level. An application built upon loosely coupled (preferably, completely decoupled) components are more robust than application built upon tightly coupled components. If the components are decoupled, only the interface needs to be changed if either of the component changes. For example, a trading partner which has been using FTP as transport protocol has moved to HTTPS. The component responsible for FTP integration may be made dormant or even removed without affecting the rest of the application. Similarly, the component responsible for HTTPS integration may be introduced with out affecting the rest of the application system. Hence, component level decoupling is implemented with in the application system. On the other hand a message level decoupling is used across the application systems. A Message Oriented Middleware (MOM) is used to implement this among disparate application systems. In webservice space, it is called Enterprise Service Bus(ESB).
• Divide and conquer: Apart from the negative connotation of this colonial rule, it is well suited for the software development. Most of the software systems are complex and difficult to manage and develop. This necessitates the division of the application system into smaller units for design and coding. These individual units loosely coupled with rest of such units make the entire application system. For example, the application may be horizontally layered into tiers and vertically split into sub-systems or domain as shown below. This division also enables component level decoupling. Two integration tiers sandwich the enterprise system, B2B integration tier facing the trading partners and EAI integration tier facing the rest of the enterprise systems.
• A picture speaks a thousand words: The B2Bi is not visual. Hence, the design artifacts such as UML diagrams should be provided to expose hidden B2B processes. On the other hand BPM is visual depicting each process steps. Meaningful diagrams also leave a paper trail, which can be re-visited for re-design or re-engineering. Conceptual and Logical model diagrams which depict different processes and their interactions for non-technical members of the project such as Business Analysts and project management must be created. Physical Model diagrams which show different components and their relationship meant for technical members of the project such as developers are to be generated. A conceptual information flow between trading partners for a credit card transaction is shown below.
1. The customer creates a shopping cart and checks out the order,
2. The enterprise system of NAI sends the credit card information to a third party credit card processing company,
3. The credit card processing company routes the credit card information to the credit card company. Some credit card companies (like Discover and American Express) authorizes or declines the transaction.
4. Other credit card companies (like Visa or Mastercard) routes the credit card information to the credit card issuing bank.
5. The credit card issuing bank authorizes or declines the transaction.
6. The credit card processing company returns the response to NAI
7. The credit card issuing bank approves the transfer of money and credits NAI account
8. If the card issuing bank suspects fraud, it initiates the fraud alert and sends the information to an investigative government agency while declining the card.
• Resist the temptation of using latest technology: (conversely, resist using extinct technology too. Implementing an application build on untested or sufficiently vetted technology put the project into tremendous risk. Many a times, the management or even the development community may be carried away only by looking at the positive aspects of a particular technology, put pressure on the architects to use that technology for the implementation of the project. If such a technology fails in the long run, the application becomes very susceptible to lack of technical and developer support. The architect has to identify the Technology Readiness Level of the technology she is implementing for the project which is almost always below the technology available at that time (Mankins,1995).
• Follow the standards: It is a good software development practice to follow the established standards used in Business, technology, legal/regulatory space. This alleviates the Tower of Babel Problem associated with B2B integration. Hence, none of the trading partners have to adopt each others messaging standard, rather follow the industry standard. Also, building a messaging schema from scratch is extremely cumbersome and time consuming.
Business: Every vertical industry has developed a XML schema standard for B2B integration. For example, if the project involves an insurance based application, then the trading partners must follow ACORD standard unless proven otherwise.
Technology: If the application necessitates transformation of XML instances (say, ACORD XML instance to trading partner canonical XML instance), use XSLT standard. If the application is built on WebServices, trading partners must follow a particular WS-I basic profile. Following a technological standard also helps to avoid vendor lock-in.
Regulatory: If the application involves legal or national security related components, it must the SOX and/or Patriot Act compliant.
• Defensive architecture: This concept is analogous to defensive driving. Not only the application must be robust and secure against the internal failures but also against the failures of the trading partners. For example, a XML message from a trading partner is intercepted by a malicious application and initiates a man-in-the-middle attack with a malicious data. Or, a trading partner advertently or inadvertently sends a message with an embedded Trojan horse.
• Build a Canonical Schema: A canonical schema enables the application loosely coupled with the external trading partner schema (or industry standard schema) and the internal business components. The canonical schema acts as shock absorber for external schema changes and the redesign or re-factoring shocks of internal business components. A canonical schema and an associated Logical Data Dictionary(LDD) ensures disparate systems in the enterprise speaks same language. There different canonical strategies for building such canonical schema. They are canonical schema derived from underlying business objects or canonical schema derived from the industry standard.
• Avoid making temporary fixes: Many a times, architects are forced to implement temporary solutions to application due to time or financial pressure from upper management. Unfortunately, many of the temporary fixes ended up become permanent especially the temporary fixes working fine. Later, the principle of if it ain’t broke, don’t fix it gives the justification not to fix it. Over the time, the application becomes less robust. Even if a temporary fix has to be applied for the current release, the temporary fix has to be corrected as first priority in the next release. Unfortunately, there are situations where temporary fixes are unavoidable. For example, the trading partner gives very short notice on the changes of purchase order schema.
• Frequent scope creep: Even the traditional application development faces occasional scope creep. The presence of trading partners in the application integration increases the chances of scope creep in B2B integration projects. The complete definition and control of the project scope involving two or more business entities pose considerable challenge. Fruitful JAD sessions with trading partners is the best way to reduce scope creep.
• Thinking about non-functional requirements all the time: The importance of non-functional requirements takes precedence mostly after the application go live. However, if not given proper consideration throughout the analysis, design and development, the application may not meet the stake holder expectations. Trying to fix non-functional requirements after going alive will be too little too late. The architect must be thinking about non-functional requirements such as performance, reliability, scalability, fail over, security, availability, maintainability, portability, re-usability and integrability throughout the analysis, design and development. Sometimes improving one may adversely affect others. For example, if the application is made more secure, it may adversely affect the performance of the application. Hence, the architect needs to prioritize the importance of each non-functional requirement as per the expectations of the stake holder. The architect must be asking himself (or thinking aloud with his team members) questions like,
How the application is supposed to handle if the trading partner sends a large document?
During down time, how to handle an incoming message?
Is the message needs to be secure at session level (using SSL) or end-to- end (using digital signature)?
What level of non-repudiation required? By receipt or by origin
• Provide only those information which have business value: Trading partners must be provided with information what they need to know, not what they want or don’t want to know. Before sending out the information to the trading partner, those information which have no business value has to be filtered out of the message. This strategy not only makes the payload light weight but also avoid providing inadvertently internal information to the trading partners. In case of errors and exceptions, convey them in a business friendly manner to the trading partners. For example, in case of a database exception (like java SQLException), instead of sending the entire stack trace to the trading partner, catch the exception and create a business friendly message to the trading partner similar to- We are unable to process your request now. Please try to resend the request after some time.
• Not all trading partners are equal: Conversely, some trading partners are more equal than others especially those ones who bring the revenue. Such trading partners can even impose their will on the architecture of the application to see whether it meets their own standards. Although, it is against the very tenants of B2Bi, the business reality bites sometimes. For example, an enterprise builds its B2Bi with XML / HTTP. However, a new integration with a trading partner with deep pockets and potential high revenue inflow requires flat file / FTP. Now, the enterprise has to re-architect to accommodate flat file / FTP. Trading partners comes with different colors and hues, some are Early Adopters (like small enterprises) and some are Early Majority (like large enterprises) and the rest in between them. Each trading partner comes with different Technology Readiness Level and different technology adoption time. So, an architect has to visualize and expect each and every such possible scenario. The key difference of such trading partners is shown below.
Type of trading partners (Geoghegan, 1994)
Innovation adoption of trading partners.
• Avoid Over Engineering (and Under Engineering): Software and hardware technologies are improving over the time with constant innovation. Architecting a project with the current technology may become obsolete beyond a point in future. Architecting for the project beyond this point is a waste of time and resources. On the other hand, under engineering will not justify ROI (Return On Investment). Since the best technology is yet to come, any over engineering will also not justify ROI either. Unfortunately, it is extremely difficult to predict the technology readiness level of trading partners. The business reality may force to accommodate trading partners who bring revenue but use obsolete technology. In other words, architects must be ready to accept every type of trading partners. The arrival of cloud computing like AWS, helps to avoid software and hardware vendor lock.
• Never ever Assume: Because of information overload associated with the architecture, Architects are tempted to assume lot of technical information. For example, during a webservice based B2B integration, the Architect decides to use what she thought as the stable version of SOAP available at that time –SOAP1.0. On the other hand, architect of the trading partner decides to use the latest version of SOAP available at that time – SOAP 1.1. Such mistakes give rise to mutual mistrust and expensive recoding. Every details of information exchange with the trading partner (such as transport protocol, messaging protocol etc.) must be written down and be signed off by both parties. The colloquial etymology of Assume speaks for itself (Assume = Making Ass out of u and me).
• Avoid multiple entries to the application system: Many of the B2Bi, also provide a web interface to the trading partner. In other words, the application is opening multiple doors for the information to enter, one via web and the other via B2B. The data validation and cleaning of data upon entering the system on both these channels and making the data in synch poses considerable challenge.
• Use Code generating tools: Using code generating tools helps to speed up the development and create clean and optimized code. Such code generating tools are analogous to building a car. Instead of building a car by himself, a driver spends his time to master the driving skills. Even if he makes one, it may not be as good as one made by car making company. However, he has the confidence of changing a flat tire or a wiper blade. But he may never dare to touch the engine. Likewise, a developer uses code generating tools to create code and tweak the code here and there. Some of the code generating tools used for B2Bi is given below.
Creating XSLT code: Using a code generating tool, create XSLT code for mapping one XML to another during design time. At run time, XML instances are mapped using a transformer (say XALAN) using this XSLT. This saves considerable amount of time coding, debugging and optimizing the XSLT code.
Creating WSDL code: Many vendors provide tools to create WSDL from the webservice end points which are to be exposed.
Creating binding XML java classes: Using JAXB generator, binding java classes can be created from XML Schema at design time. At run time, XML instance are marshalled/unmarshalled with java class instances.
• Avoid over crowding the team: Although team size may not be decided by the architect, an over crowded team adversely affects the productivity of the architect as she is the mentor to the team members and resolves the conflicts among team members. As a rule of thumb, five is a team; ten is a crowd. Beyond ten, any addition will have negative impact on the team effectiveness as shown below.Geoghegan, W.H. (1994). Whatever happened to instructional technology? Paper presented at the 22nd Annual Conference of the International Business Schools Computing Association, Baltimore, Maryland July 17-20, 1994.
Mankins, John C., (6 April 1995), Technology Readiness Levels: A White Paper, NASA, Office of Space Access and Technology, Advanced Concepts Office.
____________________________________________________________________________This document is for reference only. For actual implementation, please contact the author. No part of this blog is used or reproduced without the written consent from the roychettan@gmail.com
No comments:
Post a Comment