Sunday, January 31, 2016

Best Practices for Implementing Effective Application Architecture

In this research paper Gartner analyst points out that “Cloud deployments, mobile interfaces and advanced analytics are changing the way in which applications need to be structured. Application managers must ensure that application architecture is effective in improving the versatility, usability, maintainability and robustness of applications.”

One of the key challenges is that architectural communications are sometimes inconsistent within application development team actives. Application architects must quickly determine which of their decisions are important for the success of the project. The primary activity here is balancing the project requirements (including time and budget) with architectural requirements — and identifying what decisions will need to be made, and which architectural tools make sense to implement those decisions.

Often time I see in our organization is that project requirements take the dominant position and architecture requirements are being neglected due to the constraint of time and budget. Application architects pay more attention to the project itself rather than architecture requirements. One of the examples is that when we try to implement an application, from desired architecture perspective we should consider cloud implementation which is in alignment with enterprise architecture principle and organization’s vision and strategies. In the meantime the cloud providers on the market cannot meet all project requirements at the moment. As an application architects we should balance the architecture requirements and project requirements, we can define a transitional architecture to provide business continuity while keep the architecture requirements. Sometimes it becomes battle and ends up architecture requirements are being neglected.


Best practices make sense but require education and communication within the organization especially between project teams and enterprise architecture team. Maturity of the organization enterprise architecture plays a big role for adopting best practices.

Simplify ERP landscape to provide business with agility and better architecture asset reuse.

As this lesson states “For decades, complex distributed enterprise applications have been implemented and integrated. Some of these applications such as Enterprise Resource Planning (ERP) applications have attempted to integrate many of the major business functions into one application suite. This has been a dominant application architectural model for many years. Even with ERP systems, we still have the problem of “application stovepipes" or "islands of information" that cause major architectural reuse issues.”

Our organization owns the one of the largest and complicated SAP ERP system. Our ERP system has a long history, starting with several functional systems integrated by ALE (finance & controlling, logistics, maintenance) merged to one ERP system for EU and then merging US and APA ERP systems together. The result of the merge creates a very complex ERP system with a lot of customer specific objects, modifications of programs and data dictionary objects. Additionally there are a lot of unused code lingering in the system, unused customer specific objects, modifications and data dictionary objects.

There are many projects waiting to be implemented in the landscape and many of them being implemented and focusing on the same application, the result is the process complexity and process differentiators (like PID) are increasing.

The consequence of this complexity makes it very difficult to adopt new technology as there is no approach to remove old processes of functions or reengineer processes or functions to come to a global standard or to a core SAP standard without using modifications.

Simplifying and standardizing the SAP ERP landscape has become priority in order to provide business with agility and better architecture asset reuse. Simplifying and standardizing existing SAP landscape will allow system to be migrated to the new SAP HANA platform and adopt new SAP ERP modules. SAP ERP landscape simplification and standardization may require huge effort but benefits will be obvious in a long run.

Hadoop for the Enterprise - Making Data Management Massively Scalable, Agile, Feature-Rich, and Cost Effective


TDWI research paper Hadoop for the Enterprise indicates that Hadoop usage will become mainstream in coming years, and – more to the point – Hadoop will serve whole enterprises, not just a handful of users with niche applications in a limited numbers of industries. The report explains how Hadoop and its uses are evolving to enable enterprise grade deployments that serve a broadening list of use cases, user constituents, and organizational profiles.

In our organization we are developing Hadoop strategy and road map. From Application architecture perspective, we see many opportunities and use cases that can bring business values to the organization.

As UWE LIEBELT, President BASF 4.0, BASF SE said "We must and we will look very carefully at the opportunities and challenges presented to us by digitization. For BASF, the spectrum of possible models ranges from digital chemicals group to market leader for digital business models in chemicals." Following industry 4.0, BASF kicks off BASF 4.0 which will bring a huge opportunity of digitization from digital chemicals group to market leaders for digital business models in chemicals.

BASF Maglis project uses Hadoop to provide data information, data entry and processing, collection, compilation and systemization of data information in databases for customers in regarding to agriculture, horticulture and forestry. IoT (Internet of Thing) will connect manufacturing devices, sensors and systems together, Hadoop will provide a necessary storage and proceeding power for IoT.

Some other use cases are:

Data warehouse extensions – Hadoop can be used as a complementary extensions of a data warehouse when warehouse data doesn’t necessarily require the warehouse is migrated to Hadoop.

Analytics and BI – BI involves data exploration and discovery, which are critical to learning new facts about a business as well as getting to know new big data and its potential business values. To enable the broadest possible exploration, numerous large datasets can be co-located on Hadoop.

Data Lake and Data Hub – Both involve loading multiple massive datasets into Hadoop with little or no preparation of the data. That way, data ingestion is fast, simple, and inexpensive. This can help solving big data challenge for the organization

Predictive maintenance for the chemical manufacturing – a large amount of machines, sensors and systems data can be loaded into Hadoop for analysis and predictive maintenance.

From Application Architecture perspective, Hadoop can optimize organization’s application portfolio, bring more business opportunities and improving organization’s application landscape.

Thursday, January 21, 2016

Enterprise Architecture Stack versus Domain

From what I have learned either from the TOGAF or from previous classes we know that enterprise architecture has four domains, Business Architecture, Data and Information Architecture, Application Architecture. When we talk about domain concept it looks like the enterprise architect works in each domain separately. In our organization we started enterprise architecture practice about 2 years ago and we have three domains that are within EA organization, Business and security are outside of the EA and have their own entity and agenda. Even within the EA organization each domain works with its own agenda. Although we all know that each domain should work as the part of the development cycle as described by TOGAF ADM, in reality some of practices just do not follow the methodology.

In this class we start talking about the EA stack, each architecture domain as a layer stacked each other and provide an increasing level of detail about the organization including:
·        Its goals and objectives
·        Its organizational structure and business processes
·        Its data and technology infrastructure
·        Its systems and applications

The layers interact in both directions, both horizontally and vertically where components in one layer can consume and produce services for the layer above and below. Layer provides more dependency concept.

Whether we talk about domain or stack, they are basically the same concept, the key is to understand what is the best practice and methodology.

As I mentioned in the introduction, architecture work should start with architecture vision and understand the business needs and business processes. A good enterprise architecture practice should encompass all layers.

The Application Architecture Next Practices


The reading for this week’s topic talks about the Application Architecture Next Practices. This article posts a few key challenges
·              
·       Applications must be scalable and easy to change as requirements evolves
·       Critical capabilities, such as reporting, analysis and easy screen navigation, require rapid access to the diverse application data.
·       Enterprise application integration complexity increase time and cost of delivery and change.

My experience working as an enterprise architect for the organization strongly feel these challenges existing on multiple applications and systems especially the application complexity increase time and cost of delivery and changes. Simplifying IT landscape and providing business with agility and cost saving become EA’s main focus.

We recently have developed some architecture works and these are the challenges that we are facing and trying to address. One architecture work is to develop a global fax solution for the organization. The faxing environment the organization has today is a disconnected and traditional technology which includes traditional fax machines connecting to analog lines, multi-function devices and fax server software from different vendors. The whole environment is complex and cannot provide business with agility, flexibility and efficiency. Maintaining and supporting this infrastructure is becoming difficult and costly. We developed an architecture by introducing a clod based fax provider to provide an integrated cloud based global solution which allows users to send and receive faxes from anywhere at any time and on desktop and mobile devices. This architecture allows us to eliminate all traditional fax machines and fax function on the multi-function device and various fax server software to eliminate on-premises fax related infrastructure. The new architecture not only provides business with capability, agility, and efficiency but also reduces the complexity of the IT landscape and TCO.

Reference

https://www.gartner.com/doc/2245315/application-architecture-practices-lessons-learned


Enterprise Architecture Introduction

Introduction

From previous studies we have learned that Enterprise Architecture is a complete expression of the enterprise; a master plan which “acts as s collaboration force” between aspects of business planning such as goals. visions, strategies and governance principles, aspects of business operations such as business terms, organization structures, processes and data; aspects of automation such as information systems and databases; and the enabling technological infrastructure of the business such as computers, operating systems and networks

Enterprise Architecture always starts with architecture vision, why we need to do enterprise architecture, what we want to achieve and how we should do it. Enterprise architecture is driven by the business scenario or business requirements. Defining and creating a future state of architecture involve understanding business needs and stakeholders concerns, understanding the information flow and understanding the technologies

Enterprise Architecture covers four architecture domains
1.    Business architecture covers business strategy, governance, organization and key business processes
2.    Data Architecture covers the structure of the organization’s logical and physical data assets, data management resources.
3.    Application architecture covers a blueprint for the individual application systems to be deployed, their interactions, and their relationships to the core business processes of the organization.
4.    The technology Architecture covers the software & hardware capabilities that are required to support the deployment of the other three architectures includes IT infrastructure, middleware, networks, communications, processing and standards.

Security Architecture has its own discrete security methodology and composes its own discrete view ad viewpoints. According to TOGAF security architecture impacts the architecture development and provides the security requirements for each domain architecture development.


References

TOGAF                                                                               The Open Group
Enterprise Architecture Good Practices Guide                   Jaap Schekkerman