Enterprise Architecture that lives forever..!!!

Disclaimer : This article is based on my personal experiences when designing application side of Enterprise Architecture (particularly back-office).

"Enterprise Architecture" is a term often used in Information Technology (IT) under several contexts and usually brought up when there is “trouble” in cross platform communication. In simplest terms "Enterprise Architecture" is used to describe the overall IT landscape / blueprint for a large organization's IT systems.

Today organization's architecture can be easily compared to that of a multi-cellular organism. Each unique and complex in its own way, yet strong in its will to survive cut throat competitiveness. You all may be familiar with the proverb, “Necessity is the mother of invention”, yet today I beg to differ when I say, “Growth is the mother of invention” as organizations strive to differentiate themselves in market with innovative yet tailored solutions. And with this Growth, also comes complexity. Complexity not just in business but also in all supportive functions sustaining the organization.

In this article, I tried to explain some of the common mistakes and best practices to consider when designing the application architecture. Please read the entire article to get full perspective and appreciate any feedback.

In today's hybrid and multi-cloud environments, IT systems have become far more complex than ever before and there is no one size fits all Enterprise Architecture that can serve the ever growing needs of an organization. There is no one shiny EA tool that fixes everything.

Defining your enterprise architecture allows you to gain a comprehensive view of the entire ecosystem and, potentially, make changes that optimize your IT needs.

Many a times, when an application is being assessed for the current Enterprise Architecture, The scale of importance that is given to application is always different from one to another, may be because of business significance and cost involved, but that should not be the case always.

Significance of tools should go with its sheer complexity and its ability to serve a wide variety of complex business functions with relative ease and simplicity.

for e.g. a business reporting tool, which for a business user might be more important than back end cloud integration process. In reality it might be other way around.

and If you ask a developer, they always say my tool is the Best. Honestly I was like that before when started my career :) .

This begs the question, what is the best Enterprise Architecture framework for my organization?

To answer this, there exist several architecture methodologies like :

• The Zachman Framework for Enterprise Architecture

• The Open Group Architectural Framework (TOGAF)

• The Federal Enterprise Architecture

• The Gartner Methodology

I will not delve deeper into explaining these individually to avoid bias towards one framework and also not to undermine the others. As i said before there is no one size that fits all, each company is different and their foot print is different. Most important part of designing enterprise architecture is to understand "As-Is" and "To-Be" process and its supportive IT landscape.

Before going into the details lets understand Software evolution over period of years as time and time tools and methodologies are changed.

In or before 1980's it was always a development of huge lines of code to achieve a simple task and it was custom development from scratch for business requirements. In 1990's solutions stabilized and converted into software products. In late 1990's and 2000's many companies implemented products instead of developing custom solutions for each requirement (for Manufacturing, Finance, HR ..etc and same in the case of Integrations and reporting systems)

This really started the boom for product development across industries. As these products are matured further, their functionality merged into each other, like Reporting tools can integrate directly and there is no need of integration tools any more.

ERP systems can communicate directly to vendors or customer without any need of additional tools.

In the recent past these products started to embrace internet and open source systems to evolve into Cloud applications.

Enough of history, my intention is to specify that there are lot of products in the market that overlap functionality, This is reality in today's Enterprise Architecture when it comes to ERP, Integration tools, Reporting Tools, Data governance, Budgeting and Forecasting tools..etc

For Example: What can be done in Hyperion, can be done in Oracle GL, Need for Informatica Integration can be fulfilled by Qlik directly. Like this there are many examples.

Some of the key things to bear in mind while evaluating or designing an Enterprise Application Architecture are as follows:

1. Integrations

2. Master Data Management

3. Reporting Standards

4. Application and Technology Footprint

Integrations :

In a complex IT ecosystem, the need for integrating applications and data exchange is high and integration plays an important role in Enterprise Architecture. Integrations are more complex than ever and different layers of integration further adds to the complexity of the architecture.

Some high level rules for integrations to bear in mind:

when designing the integration, we should set standards to follow the same practice across the systems, whether it is Web-service calls, API, Staging tables or File transfers, Should be consistent across.

• Set up standards - when designing the integration, set standards to follow and practice across the systems, whether it is web-service calls, API, staging tables or file transfers.

• Consistency matters - Ensure consistency across platforms when setting standards, be it naming, coding or process standards.

• Keeping it simple - Direct integrations - Systems that can directly be integrated using vanilla capabilities, should. Avoid customization or tailoring code to fit business needs as much as possible and leverage existing out of box features for integration. Avoid complex queries and create views in source or target databases

• Business Logic - Should be kept to bare minimum in integration tools and should always be handled either on the source or target system. This will create better visibility to end users.

• Transformations in the tool should be kept to a minimum.

• High visibility of failure notifications.

Specially, ERP integrations should be designed to optimize Enterprise Architecture since ERP will be the largest software on the architecture map.

Master Data :

Management of Master data is critical in Enterprise Architecture. Master data (Suppliers, Customers, Cost Centers, Accounts, employees ...etc ) plays a significant role in Shaping Enterprise Architecture integrations. Since every integration that is connecting two or more systems will have some form of Master data communication in it.

There are some MDM tools that maintains the Master Data management. It is not necessary to always use MDM tools, and MDM tools usage depends on various factors like data volume, audit/approvals, connectivity, no of applications using master data, size of the organization). The intention is that Master data should be consolidated at one or few applications, to minimize issues and sync programs else there will be a lot of missing data issues.

Reporting Standards :

Each company has multiple sources for reporting for each application, causing redundancy of information, timing issues, and difficulty replacing old reporting technologies (Discoverer, Essbase ..etc)

There is no one reporting solution that fits all, there are different types of reporting :

• Analytical Reporting

• Transactional reporting

• Period closing or Reconciliation reporting and ..etc

We should be cautious of segregating requirements and all reporting requirements should be consolidated and analyzed through the categories understanding frequency, data volume, time sensitivity and target audience.

Application and Technology footprint :

Last but not least, Application footprint and Standardizing programming standards has a perpetual impact on Enterprise Application Architecture.

Minimizing application footprint by achieving required functionality in preferred product hierarchy helps save lot of hidden costs and simplified EA.

The biggest challenge of IT is its resources with strong skills and expertise in tools. The more systems and technologies we inherit, the more complex we become and the more the need for system experts with knowledge on the tools. Indirectly with more technologies and applications, we dilute the expertise.

As part of minimalist approach, we need to follow a preferred coding language and preferred product hierarchy to simplify or reduce the need for specialized skill sets.

Often Developers/Contractors prefer to develop in their own coding language or frame work that they are comfortable with. Enterprise architects we must oversee and set standards for development.

Organizations have different setup and needs. In the simplest terms, Designing an enterprise architecture should be a tailor fit to each organization.

Enterprise Architecture never gets enough significance and also enterprise architects have come under substantial criticism for failing to meet their promised goals. The reason for this is that many architects do not understand the the right As-Is and To-Be state.

It is important to create an Enterprise Architecture team that governs and looks through all the processes and IT landscape in the company and any change in IT process or footprint should be approved by enterprise architects.

In summary, make sure to minimize technology foot print , optimize integrations, implement right standards, build expertise in a core areas of architecture.