Solution Architecture for ERP Implementation

In the summer of 2007, I had the opportunity to work as the Solution Architect for a global program of a world leading organization with operations across 3 continents.

The organization had implemented / was in the process of implementing Oracle Applications solution across the entire organization. For each project they had a process of assigning a solution architect whose responsibility was to deliver a Solution Architecture Document.

This organization had a well defined Architecture department with over 400 architects. The team included specialists in the area of applications, information services, security, disaster recovery and operations. The team also included a set of Enterprise architects and a group of Solution architects.

What is the difference between Enterprise Architects and Solution Architects? While the enterprise architects fussed on the overall architecture of the company, Solution architects were specific to each project. Every project started off with a solution architect.

I was the solution architect for one such project.

The article below intend to highlight the solution architecture processes for an ERP implementation.

As per Zachman's model, the architecture of a company can be grouped under the following areas. Contextual, Conceptual, Logical, Physical and Detailed. In each of these areas, the architect need to ask the following 6 communication questions (What, where, when, why, who and How).

For solution architecting for my project I concentrated on the Conceptual, Logical and Physical part of the above 5 application areas.

In a typical ERP implementation, you will need to architect the following areas:

1. Overall architecture

2. Context

3. Application Architecture

4. Information Architecture

5. Infrastructure architecture

6. Security Architecture

7. Operations and control architecture.

In each of these areas, you start off with a conceptual architecture, which is then detailed into a logical architecture and finally further elaborated into physical architecture. While the conceptual architecture is at a high level, the architecture gets progressively elaborated as we move to the lower levels.

The detailed architecture is nothing but the configuration document which is essentially an output of the project team.

Should the Solution architect be an expert in each of the above areas?

No, solution architect should be an expert in one of the areas and should have a clear idea of the business. The role of the the SA is more of a co-ordinator who identifies the key resources / experts in each of the above areas and gets their inputs and consolidates the same into a single Solution Architecture document.

Overall Architecture

This is like an introduction to the Solution Architecture document and sets the stage for the details that follow. Overall architecture talks about the high level architecture for the solution. While it should not be very detailed (so as to break the mystery as it were) while it should also give sufficient high level details to spur the interest of the reader / user of the Solution Architecture document.

Context

Every project happens within a context. The context could be either a business context or a technological context. Sometimes the context could be the IT vision of the organization where it plans to implement the ERP solution as a prelude to implementation of other value added applications / solutions etc. Most of the time, the context is the high level, near / medium term IT roadmap of the organization. It is very important for the Solution architect to understand, document and validate the context under which the ERP implementation is being undertaken.

Application Architecture
Normally, when we talk of solution architecture, we tend to consider onlr the application architecture aspect of the ERP implementation. Almost like a primordial reflex, the solution architect will go around collecting information on various applications that integrate with the ERP system and then prepare a neat Visio diagram with many boxes and arrows showing the various applications and their integrations.

While primarily application architecture does that, it also does something more. Primarily the application architecture looks at:

1. The application landscape: In this the solution architect identifies the various applications that interacts directly and indirectly with the ERP system. For example, if application A provides inputs to Application B which in turn provides inputs to your ERP system, both applications A and B should be reflected in your application architecture.
2. Type of integration: There could be a number of questions that the solution architect should ask when he / she is looking at under the above heading. Key aspects to be considered include the data flow direction. Is it inbound (data flowing into the ERP system) or outbound (ERP system is providing information to another application)., Another aspect, is relating to scheduling. Is the integration going to be real time or batch. Yet another aspect relates to the integration type, will it be point to point, through a SOA based middleware, through FTP, or based on Workflows. My suggestion is that for small companies, it is very risky to go in for SOA based integrations since customer may not have the wherewithal to manage the same after go live (SOA consultants tend to be very expensive, and the whole SOA and BPEL tend to be very knowledge heavy).
The application architecture will have a close linkage with the Operations architecture mentioned above when it comes to Batch Program based integration and error detection and tracking.

Information Architecture

This closely corresponds to the application architecture. Information architecture deals with the type and volume of information that passes between various applications as well as between different modules in the ERP application. Information architecture deals with the following questions.

1. What is the type of information that flows between different applications.

2. What is the direction of information flow?

3. What is the volume of data flow (normal, peak)

4. What are the workflows and approvals that accompany these information flow?

5. What are the various documents that flow between the applications? Are they maintained in physical form or electronic form?

Infrastructure Architecture
Infrastructure architecture should consider the following. This is a very highly technical aspect of the Solution Architecting and Solution architect will do well to consider these aspects very early in the solution. Also this is an area which undergo a lot of changes and finally this is the area which, if not done correctly, can lead to lots of performance issues in the future as you near go live.

1. Hardware sizing: This is normally done by the hardware vendor. However it is very important for the Solution architect to have an idea of the logic used behind the hardware sizing.
2.No of nodes: This is a very important decision. In single node installation a single, parent server takes up all the performance load while in multi-node installation, multiple nodes share the performance loads. Multiple nodes help in load balancing and performance optimization. However, post go live management is better with single node installations. And finally, the installation complexity is higher with multi-node installations. Most of the time, this is a decision taken as a part of point 1 above.
3. Disaster recovery architecture: One aspect of Infrastructure architecture, esp. in big implementations is related to planning for disaster recovery. Here, questions abound. Some of the questions are: Process of disaster recovery: How will the disaster recovery be handled? If we are going for a separate server / data center, where it will be located? What s the lead time in moving from the main server to the disaster recovery server? Volume of data that need to be reentered in case of moving to the new server/ Load balance of disaster recovery server, for example, during normal hours, only a part of the server need to be dedicated to ERP and other applications can run on the same, but during the disaster period, many of the other applications will need to close to pave way for more load to be used by the ERP application. Another aspect is relating to the access to the application. How will the functional users be informed of the disaster and how they will start accessing the DR server? And finally, disaster recovery also should plan for data reentry by having buffer resources to enter the data backlog.
4. Moving back to the main server. Part of the disaster recovery architecture should also consider the process of closing the DR server and moving back to the main server once the core issue have been resolved. Since this is a planned activity, it is much less complex. Detailed procedure documentation and approval processes should be maintained during the entire process of moving to the DR server and then moving back again to the main server.
5, Application performance: In a 3 tier architecture, the information is entered in a thin client and this gets processed in multiple servers in the background. This could lead to a lot of wait time for the user between the time he / she enters the data and the system fetches back the process data. For most of these parameters, there are clear international benchmarks which the technical consultants should be aware of.

Security Architecture
Security Architecture is concerned with ensuring the security of the application and the data base. The security architecture for this solution is dependent on the overall security policy and network access policy of the organization.

Typically the security architecture should cover the following aspects.


1. Data Security: How will the database security will be maintained? How will the administrator maintain the passwords? How can the database password be protected? What is the policy for granting access to the database.

2. Application Security: How will the application be secured? How will the access to the application be controlled? How will the activity in the application be monitored? What kinds of Alerts are required? What are the possible error scenarios? How each scenario will be managed? What is the application security policy?

3. Access Control: What is the firewall policy of the organization? What is the network access policy? What is the application access policy? Will single sign-on be used? Will Active Directory be used to manage accesses? How the access to the network be managed from within the country? From abroad? What is the process of IP Management? Will static IP be used? Will dynamic IP be used? Will VPN be used? What is the process of accessing the network? Is logging in to the network mandatory for connecting to the application? Will separate accesses be used for database and application?

4. Password Policy: This policy applies to the management of passwords for the network, the database and the application. The key aspect here is the ownership hierarchy. Some of the questions that need to be addressed are: How are passwords going to be managed? Will we have tracking of passwords history? How frequently the passwords will be maintained?

5. Inactive accounts management: How will the inactive accounts be identified? Managed?

6. New account creation: What is the new account approval and creation policy? What is the procedure? What is the document tracking?


Operations and control architecture

This part of the solution architecture covers how the standard day-to-day operations on the application will be handled on an ongoing basis once the application goes live. The key questions that need answering are:


1. Back up strategy: What is the frequency of database backup? what is the frequency of application backup? Will it be a cold backup (Application and database are stopped before backup) or a hot backup? What is the tool used to keep the backup? Will the back up be on a CD, on tape or on another drive? How many days of data backups will be maintained? What time of the day the backup will be taken? What is the expected duration for taking the back up? For restoring the applications?

2. Process scheduling strategy: Every application will have a set of batch processes that need to be run during lean periods. So the questions are, What are the key processes to be scheduled? What are the interdependences and sequences? How will they be scheduled? What is the strategy in case of a process failure? What processes will be run during the weekdays? What processes will be run on weekends? On holidays? Who are the owners of the processes?

3. Performance tracking: The administrator should regularly track the performance of the system. This aspect of the architecture asks questions like, what are the key parameters to be tracked? How will the admin know that intervention is required? What are the expected issues and expected resolution plans?

Conclusion:
That's it. I have finally concluded the writeup on Solution Architecture. Most of the time initially, the Solution architect will develop the logical architecture and progress it will details of physical architecture as they emerge. In this way, the solution architecture document is an evolving document. While the solution architect should ideally be focusing on the end user (A house is there for people to live, nor for carpenters, plumbers and electricians to produce their deliverables), unfortunately, Solution architecture is considered as a technical activity most of the time and hence do not get the due review and importance from the project implementation team.

And that is the tragedy of the Solution Architect.....