From EA 871 to EA 874, Organization Stability to Innovation

In EA 871, we talked about the organization. The organization is an open and ecosystem, it has its input and output, it has the characteristics of followings

·       A common goal, defined by the corporation, to which all employees aspire

·       The definition of a hierarchy of tasks and corresponding positions aimed at reaching the goal.

·       The reliance on expertise, skills, and experience relevant to the defined positions

·       The definition of specific standards of work and products

·       The establishment of rules that serve the interest of the organization.

·       The recognition that rules and regulations bind managers as well as employees.

Organization has been stable and most employees work for the organization in their entire career. Some changes happened within the organization but overall organization, processes and people are relatively stable. Even though we talked about the EA causes organizational change in a way the EA is to define a future state of the organization and identify the current state and finds gap between current and future state of the organization, then create a roadmap to transform the current state to the future state. This concept has been somehow changed over the course of study especially in this class, EA 874. Innovation and adopting emerging technology in this digitized economy becomes dominant theme. Disruption becomes part of the corporate DNA and it is encouraged to embrace disruption.

The article “Transform Your I&O Organization into An Innovation Machines” states that “In the age of the customer, it is more important than ever for enterprises to innovate to difference. The current economic turmoil provides the best possible justification for innovation. Organization must be “Built for Change”

While innovation and change are inevitable in this digital economy and data business, I would argue that the organization needs to keep certain stability both organization and people in order to innovate and change, after all people first. For the past year I have seen so many people are leaving the company or find a new position within the organization in order to keep their employment in my 30 years career. Productivity has been deteriorated and people are wondering where they will end up with tomorrow. While we know it is necessary to change, this kind of change could lead to instability of the organization and affect the innovation in the end. 

Organizations built for change

Organizations are built to perform, not to change. But in today’s highly competitive business environment organizations must be ready to change and change frequently. (Lawler & Worley, 2006)

“Technology trend and Technology vision 2016” by Accenture indicates that in today’s digital economy, 25% of the world’s economy will be digital by 2020. With digital pervading everything, its bringing with it ubiquitous and unprecedented amounts of change. There are new technologies and solutions, more data than ever before. These changes are no phase. Change, in fact, has become the new norm.

Today’s business is digital and data business, with the characteristics of big data, data comes in with velocity, volume and variety, it is impossible for traditional IT to handle, change is inevitable. Changes are everywhere, business, IT and people and organization must be built for change. Changes mean how you operate as a company. Moving at the speed required for a digital business means developing new skills, new processes, new products and whole new ways of working. New IT’ is essential, with DevOps models and practices to drive continual delivery, service oriented architecture (SOA) and the cloud for scalability, software-as-a-service (SaaS) for efficiency, architectures built for agility, and platforms for collaboration.

Changes are reflected within our organization almost every day. Organizational change, new strategies, technologies change and people moving. New organizations are formed, new projects and initiatives are conducted and presented, datacenter outsourcing, operating model change. Yes changes are everywhere and changes are inevitable.

What does this mean for EA? EA is a catalyst for organizational change, in the meantime EA should also create a holistic view for change and guide change to the desired state of the organization. EA should foster organization innovation, stay up with emerging technologies and create solution space for business.  Change can create disruption and turmoil, EA should embrace disruption and envision and encourage innovation and introduce new technologies to help organization to meet challenges while creating agile, efficient and effective architecture for the organization.

Reference

https://www.accenture.com/us-en/insight-technology-trends-2016.aspx

IT Operations Organization Innovation

Gartner research paper “Foster Innovation Within Your IT Operations Organization” states that “Most IT operations organizations are not natural homes for innovation. With the current high levels of change in technology, business and society, it is essential for them to become more innovative to remain viable.” It further states that “IT operations organizations are not traditionally known as fountains of innovation, and current incentive systems may in fact encourage the wrong behavior. What makes this situation potentially perilous is that many of IT's customers now have more options, such as the public cloud for the hosting of their services.”

Indeed traditional IT is to provide services to the business users, rarely thinking about innovation within the organization. As a matter of fact, which is very true for our organization, many of our IT customers or our business units now have more options to implement IT solution for their business needs without even consulting IT. The reasons behind this behavior are mainly two folds, software vendors now are providing total solution, while organization IT can’t stay up with emerging technology and lack of innovation. Even though from enterprise architecture perspective we try to simplify IT landscape to eliminate and reduce complexity for IT implementation and operation, it is not enough to convince our business customers if we can’t provide solution quick enough with emerging technologies. For IT to survive even within the organization, IT operations need to encourage innovation. In our organization our strategy is to become business solution provider, we emphasize in the following areas for business to buy-in and build trust relationship with customers.

·       Closer operation with our customers

·       Increased effectiveness and speed

·       New and innovative services

·       Enhanced internal alignment and transparency

·       Differentiated services and quality

·       Competitive cost and increased efficiency

Reference

https://www.gartner.com/doc/1803214/overview-foster-innovation-it-operations

Business Architecture

Based on TOGAF framework, business architecture is one of the enterprise architecture components. To develop an enterprise architecture, a knowledge of the Business Architecture is a prerequisite for architecture work in any other domain (data, Application and Technology), and is the first architecture activity that needs to be undertaken. Business Architecture often as a means of demonstrating the business value of subsequent architecture work to key stakeholders, and the return on investment to those stakeholders from supporting and participating in the subsequent architecture work.

Business Architecture is the second development phase based on TOGAF Architecture Development Method (ADM). It is about documenting the fundamental organization of a business embedded in its business process and people, their relationships to each other and the environment, the principles governing the design and evolution and how to organization meets its business goals. Artifacts created during Business Architecture development phase will provide baseline and requirement for the rest of architecture development. Some of the key artifacts are Business service/information diagram, functional decomposition diagram, business use case diagram and process flow diagram.


From enterprise architecture development perspective, it is necessary and makes logical sense to start with business architecture, but as mentioned in the class, the Business Architecture Layer is the most immature layer of the traditional Enterprise Architecture layers, most organizations do not have business architecture organization. In some cases some of the key elements of business architecture may be done in other activities like business strategy, planning. Business modeling and business process are defined by organizational strategic and high level business planning. EA develop EA principles and guidelines based on organizational vision and strategies to guide the EA practice. Business case and business requirements are carried over from Business Relation Manager (BRM) or Line of Business (LOB) users. In this case there will be a need for the Enterprise Architecture team to research, verify and gain buy-in the key business objectives and processes that the architecture is to support. This requires some additional effort for EA to reach out and to sell what EA is going to and is developing. While this approach is very common in many organizations it puts Business as EA customer rather make business as part of EA. 

Reference

TOGAF The Open Group

Enterprise Solution Architecture

Gartner’s research paper “Enterprise Solution Architecture: An Overview” brings a different and interesting concept. By studying TOGAF we know that enterprise architecture and solution architecture have their own concentration. Enterprise architecture works on a high level and creates architecture building block (ABB), solutions architecture creates solution building block (SBB). ABB is high level and abstractive, ABB is vendor independent, while SBB is an individual solution and a detailed design of a specific solution, SBB is vendor specific.

Enterprise architecture is to create solution space, create an architecture to guide a detailed solution design. As an enterprise architect I have created several solution space or enterprise architecture. Our job is to gather business requirements, working together from data, application and technology perspective to create an architecture to address business concerns and needs. Output of our work is to produce architecture definition documents (ADD), a blueprint and transformation road map. We continue to work with solution architects to design a detailed solution. The output of solution architecture is to create solution definition document (SDD). SDD includes a detailed description of the solution, implementation and operation details as well. As pointed out by Gartner “A solution is an implemented system that solves a business problem. A solution is much more than any application software it may incorporate: It includes infrastructure, people and any other aspects necessary for a business problem to be solved. A solution is delivered to the enterprise, and then altered, upgraded or retired through change projects. Each solution has its own separate solution architecture — that is, the description of how it is built and the capabilities it provides.”

Now it comes an Enterprise Solution Architecture. This concept addresses concerns what Gartner described as key findings in the article.

·       Many EA teams struggle to define the relationship of their EA deliverables and guidance to individual solutions and solution delivery projects, as well as portfolio management.

·       ESA provides that link, yet this is typically the least understood and least mature aspect of EA.

·       EA must provide or directly support project-centric solution architecture work.

“An ESA describes how all the separate EA viewpoints come together or are integrated into implemented systems or solutions. It includes each individual solution architecture, separately defined. The ESA defines how different views are leveraged within each individual solution and within whole sets or portfolios of solutions. It also includes repeatable rules for how to implement solutions in more repeatable or reusable ways — such as solution patterns, which leverage patterns and other models within separate viewpoints.”

ESA is composed of requirements, principles and models, but in the case of the ESA, these artifacts guide enterprise architects and solution architects in composing and reconciling the artifacts found in the independently developed viewpoints.

Often time different domains within enterprise architecture organization work on their own architecture and look at their own viewpoint, different architecture work are not truly integrated and linked. More or less each architecture or solution space is to address an individual business problem rather to address business challenge as a whole, some sort of separation and isolation exist within EA domains. ESA concept is useful to consolidate and unify architecture definition from different architecture domains to create an integrated and reusable architecture for the organization.

Business Use Case Driven Enterprise Architecture

As mentioned in the class “If the scope of the Enterprise Architecture practice is limited to primarily the domain of the IT organization then Business Architecture may be a separate group that would be a contributor to the EA process and not fall completely under the domain of the Enterprise Architecture practice. The nature and structure of Business Architecture varies greatly from organization to organization today.” (EA 874, Dr. Fusco)

Whether or not Business Architecture is under the domain of Enterprise Architecture, enterprise architecture practice of organization always starts with business case or business scenario. The purpose of Enterprise Architecture is to provide business capabilities with agility and efficiency by simplify and optimize organization’s IT landscape, to consolidate IT system to improve user satisfaction, to bring in new technology to help organization’s innovation. Even though Business Architecture is not within Enterprise Architecture organization, all of enterprise architecture activities trigged by business requirements or business case.

Predictive Maintenance using Hadoop for the Oil and Gas industry is an example of such.

Oil and gas companies have a major opportunity to increase efficiency and reduce operational costs through better asset tracking and predictive maintenance. While failing oil prices, oil and gas companies are facing increasing pressure to reduce operating costs and manage the business more effectively and efficiently.

Physical inspection of equipment in remote locations is typically an expensive process. This lack of visibility can lead to equipment failure and costly unscheduled maintenance and non-productive time (NPT). Predictive maintenance allows company to collect data from sensors. The data will be huge which requires big data solution. Enterprise architecture team will create an architecture which includes data, application and technology. Hadoop can be application and technology solution to address this big data challenge. The solution can provide capabilities to store and process real-time sensor data, Ingest and analyze real-time sensor and historical data alongside maintenance data generated from industrial equipment of production, and then predictively learns patterns of normal and errant behaviors to provide warning.

Within our organization, we do not have formal business architecture organization but EA works closely with BRM and LOB managers to get business requirements and identify business use cases, then EA is to create solution space to meet the business requirement and challenges. 

Security Architecture Consideration for Hadoop Implementation.

One of the biggest concerns in our present age revolves around the security and protection of sensitive information. In our current era of Big Data, our organizations are collecting, analyzing, and making decisions based on analysis of massive amounts of data sets from various sources, and security in this process is becoming increasingly more important. The more data you have, the more important it is that you protect it. It means that not only must we provide effective security controls on data leaving our networks, but we also must control access to data within our networks

Nowadays every organization is facing big data challenges and most organizations turn to Hadoop for the big data solution, so is our organization. Recently we are developing a Hadoop architecture strategy and roadmap, one of the architectures we need to develop is the security architecture for Hadoop implementation. Based on different business requirements and organization’s enterprise architecture principles Hadoop implementation can be on-premises or in the cloud. There will be different security concerns for different implementation.

Within our organization enterprise architecture group works closely with security architecture to first identify and understand business use cases and based on each use cases requirement to create a security requirement catalog. We will categorize the requirements into different categories and identify the existing security architecture to analysis the gaps. Considering the massive amount of data that nodes hold, there is an increasing need to focus on security architecture for the Hadoop cluster. We realize that if we are going to implement Hadoop cloud solution, business critical and sensitive data will leave the premises so adequate security controls is necessary. We prefer to adopt Security as a Service provider and the architecture should consider to integrate the Security as a Service into our organization security ecosystem for consistent operations and auditing. Some of the security consideration will be

1. How to enforce authentication for users and applications?
2. How to integrate internal data sources to the Hadoop cloud?
3. How to enforce data access control based on existing access control policies?
4. How can Hadoop integrate with existing enterprise security services?  

In our fast-paced and connected world it is critical to understand the importance of security as we process and analyze massive amounts of data. This starts with understanding our data and associated security policies, and it also revolves around understanding the security policies in our organizations and how they need to be enforced. 

Security architecture development approach

Based on the TOGAF, security concerns are pervasive throughout the architecture domains and in all phases of the architecture development. Security is called out separately because it is infrastructure that is rarely visible to the business function. Its fundamental purpose is to protect the value of the systems and information assets of the enterprise. Often the nature of security in the enterprise is that it is deemed successful if either nothing happens that is visible to the user or other observer, and/or no damage or losses occur to the enterprise.

The generally accepted areas of concern for the security architect are:

• Authentication
• Authorization
• Audit
• Assurance
• Availability
• Asset Protection
• Administration
• Risk Management

When we develop enterprise architecture, security architecture will be all around each phase of the development, security requirements need to be taken into the consideration during the each phase of the development. Here we are talking about creating security architecture not security policies for a special projects. I have experienced a situation during the development of architecture of cloud solution for the organization. When I was working with security specialists on the subject usually I will get a set of policies or even a specific product to use. To me it is different. Some of the general security policies developed based on the past and existing information and technology system may not fit for this architecture. The right approach should be as described by TOGAF, gathering current and emerging security requirements from business for each phase of the architecture development, create a security requirement catalog, perform a baseline analysis to determine the “current state” of  the security effort, identify gaps in the current state, articulate an architecture in functional terms to address the gaps and incorporate emerging business requirements, identify and communicate s “desire state” environment and develop a blueprint for the future architecture. It is important to develop and select standards and policies to implement the security program within the context of the chose architecture. Business requirements should be updated and reassessed during the iteration of the architecture development process.

Reference

TOGAF

https://www.giac.org/paper/gsec/610/building-enterprise-security-architecture/101447

Integrating Security Architecture into Enterprise Architecture

One of the key findings of Gartner research paper “Aligning Security Architecture and Enterprise Architecture: Beast practice” is “The more-closely aligned the security architecture function is to the enterprise architecture (EA), the more effective it is. Complete integration of security into the EA must be the goal.”

In this research paper, Gartner indicates that “The goal is for the security architecture to be completely integrated into an organization's EA.” In reality, as stated in this paper, “many realities mitigate against achieving this in most organizations, including historical organizational and internal political realities. Security architecture has traditionally been practiced separately from the EA. Thus, security architects are often not conversant with EA terminology, principles and practices. Furthermore, the EA tools used by most organizations do not allow for security artifacts to be fully integrated with the EA, simultaneously being able to provide a separate, security perspective where security-only artifacts can be modeled.”

This is what I see in our organization today, in certain degree we don’t even have security architecture in place in general.

EA is difficult to interact with security architecture group, there is no formal communication mechanism in place. While EA creates solution space for the business, security architecture was not in the consideration of the design. Most of the security specialists (I will not call them security architects as most of the them are only concentrating on designing a detailed security solution for the projects rather than creating an architecture) don’t quite understand what enterprise architecture is. Often time this creates conflicts and misunderstanding between EA and security. The security solution, policies for a specific project is isolated from other security policies and solutions even for a similar project.

Gartner provides strategies to improve the level of alignment which I fully agree and I think our organization should adopt.

·        Sending security architects to attend a training course on the EA methodology used in the organization

·        Aligning the structure and methodology of the enterprise information security architecture (EISA) framework with the structure and methodology of the organization's EA approach

·        Adopting EA terminology in the EISA practice

·        Leveraging any focus on IT governance in the organization to support the effective integration of security into the IT services and application life cycles, and thus into the EA process

·        Conducting joint workshops between the EISA and EA teams to develop common processes, process interfaces and terminology

·        Combining EISA and EA in major new projects

·        Placing security architects in the EA team — that is, starting to work toward integrating the EISA team into the EA team

Reference

https://www.gartner.com/doc/790521/aligning-security-architecture-enterprise-architecture

Virtualization, Do Not Turn Cost Saving Into Money Wasting

Virtualization has become the cornerstone of every enterprise's favorite money-saving initiative. By reducing the numbers and types of servers that support their business applications, companies are looking at significant cost savings. Less power consumption and a smaller server footprint is simpler to manage.

Beyond the potentially dramatic cost savings, virtualization can greatly enhance an organization's business agility. Also, this technology offers the potential for a fundamental change in the way IT managers think about computing resources.

Server virtualization brings a lot of benefits to the organization. However there are some challenges presented to the IT operations as well.

Cost Justification

When implement virtual solution for data center, we need to clearly understand the business requirements and carefully plan for the capacity and infrastructure growth. If not it will actually posts a very big challenge for IT operations. Very often we see resources being wasted due to many different reasons such as whether resources can be shared among different applications due to security consideration, ongoing project postponed due to the budget constraints or resource conflicts. Hardware for the virtual infrastructure has its life cycle, when resources cannot be fully utilized within its life cycle, resources will be wasted. A typical example will be virtual infrastructure implemented for the project, the idea is to consider easy future expansion so resources were planned for the next six months or a year, then often the case the project delayed and resources sits there. After three to five years hardware resources need to be refreshed and new investment has to put in place.

Resources Calculation and Planning

Even though organization’s data center usually has a resources and capacity planning team, the reality is if you browse most of the organization’s virtual infrastructure you will find out that overall around 40 to 50 percent of resources are always idle. While a lot resources sitting idle new resources continue to be implemented as some of the resources are not suitable for some applications. While virtualization provides business with agility, it is with the extra costs. We often see that even within one data center, due to the fact that data center needs to provide infrastructure for different business units and due to some regulation and policy, applications cannot run on the same hosts thus more hardware and licenses will needed.

Virtual infrastructure management

For a large organization it is very complex to manage such virtual environment, user access rights and admin access rights to different farm, folder and resources are all need to be managed. Multiple virtual center servers, different version control and so on.

People are always talking about the benefits of virtualization but if we do not plan or architect it well, resources waste can happen easily. Instead of cost savings, it actually turns into money wasting. 

Using EA Principles in Enterprise Technical Architecture

Reference

Gartner: Toolkit Best Practice: Using EA Principles in Enterprise Technical Architecture

Enterprise technical architects — that is, technical architects, infrastructure planners, project architects and solution designers — often want to get straight to product comparison and selection. However, better enterprise technology viewpoints, ETA modeling and design work should reflect careful integration with overall business goals, as well as adherence to particular IT drivers and specific technology guidelines and best practices. EA principles are part of the guidelines to leverage — and leverage explicitly. Principles present expected behaviors that if adhered to will enable strategies to become realities.

We Enterprise Architects specify enterprise architecture principles based on organizational vision and strategies. Principles and Standards provide a firm foundation for making architecture and planning decisions, framing architecture and supporting resolution of contradictory situations. Architecture principles guide our architecture work, our decision making and choice of selection. As Gartner indicates “Choosing which principles are appropriate for a given organization at a lower level — for example, for standard ETA models such as technical patterns and technical services, or for particular individual infrastructure designs and implementations — should reflect the general goals of the organization at a high level.”

One of the big challenges for success architecture work is to incorporate a principled approach to designing technology and infrastructure. Each enterprise architecture team has a set of enterprise architecture principles but they are not always applied or used by architects during their architecture definition process. For principles to work a governance framework must be defined: the definition of a principle should specify the decision that has to be made, the choices (eventually), the body (role) that makes the decision and the typical use case (when to use it).

Finally, principles enable continuous improvement of the processes and artifacts. The more organizations know about the principles that guide their decision making — and the more specifically they document these principles in general (and in standard models), and then in per project designs document specifically how the principles are followed or broken — the better their models and designs will be.

Using EA principles in enterprise technology architecture reflects the maturity level of organization’s enterprise architecture. Less mature enterprise architecture often conducts architecture work without fully incorporated a principled approach, ended up with more project centric rather than architecture centric work. Understanding the importance of using EA principles in defining architecture is a critical factor for successful EA.

IPv6 Readiness and Architecture Approach

The most fundamental IT component of an enterprise is the network. The network must evolve to meet changing business requirements. Communication is required for organizations to function, yet costs need to be appropriately managed, and the portfolio of network services delivered by IT organizations should be formalized. The network architecture is a major subcomponent of the technology infrastructure architecture that specifies the design of the communications network. The network architecture framework specifies information such as the network components, their configuration and operating procedures. (EA 874 Enterprise Technology Infrastructure Architecture). 

Most organizations today do not have IPv6 enabled or deployed for production use, it is foreseen that support for IPv6 devices and communication will become increasingly demanded. There are many areas that require IPv6 ready, one area that will require IPv6 is Internet facing services and support for IPv6 only clients. Another area is the Internet of Things, which will bring a proliferation of IP connected devices. IT organization will have to prepare for this very lengthy and large transition to the next generation IP protocol, IPv6. The challenge of migration from an IPv4 network to a federally mandated IPv6 network is becoming a reality, and careful planning of your IPv6 transition will be critical to your success.

Organization needs to develop a future architecture to support current and future requirements for IPv6 based communication. The architecture should address and support the new business solutions that will require the next generation of IP Protocol. In addition, prepare a transition outline and roadmap to realize the architecture. Some envisioned basic preparation phases should cover scoping, training, business cases, and audit of baseline situation.

Organization first needs to assess the implications of IPv6 for the environment, including product compliance, address provisioning and management, routing policies, security, and infrastructure design. This assessment also identifies opportunities to take advantage of IPv6 features and functionality to simplify the environment, as well as areas of risk to be considered during transition to IPv6.

Organization should consider to establish an IPv6 working group to determine the training requirements for levels of IT personnel, such as network engineers, system engineers, helpdesk analysts and security engineers. Determine scope(s) of IPv6 deployment, identify business use cases such as Internet of Things. Audit the existing environment to determine the baseline “as-is” situation and then define the “To-Be” architecture blueprint for each scope.

Internet of Things (IoT) Architecture Platform and Development Approach

Internet of Things (IoT) is about equipping physical objects with smart sensors or actuators and the capability to exchange data amongst each other or with computer system via an IP-based network. The Internet of Things allows objects to be sensed and controlled remotely across existing network infrastructure, creating opportunities for more direct integration of the physical world into computer-based systems, and resulting in improved efficiency, accuracy and economic benefit.

Essentially, IoT expands IP-based networks, like the internet or company-owned intranets, beyond traditional computing devices and shifts it from the digital into the physical space. IoT makes use of synergies generated by the convergence of consumer, business and industrial internet and creates a global network connecting people, data, and things.

IoT means that there is a lot of data extracted from different devices and systems. This data can be an opportunity for a lot of improvements and changes, when interpreted right (e.g. for optimizing the supply-chain-management). Today, most IoT applications are about reacting to the measured data. In future the data could be used a lot more to not only react to a specific situation but to predict what will happen next (e.g. predicting the failure of specific parts of a machine). Therefore IoT will often be combined with Big data & Analytics and IT as a Service (also known as Cloud computing) capabilities to process the vast amount of data and to derive valuable knowledge out of it.

The IoT platform architecture(s) should satisfy the business requirements of today, and position the organization for the future growth in this area. Both vertical and horizontal integration must be strongly considered, and the architecture must enable this through the use of industry standards. Architecture development approach should follow a modular approach to start small and grow smart. This will create an adaptive architecture to cater to dynamic business requirements, driven by business projects.

The approach and general steps to develop the IoT Platform Architecture are:

• Consider the most preferred theoretic target, the ideal scenario based on the greatest potential business benefits
• Assemble the identified use cases and potential vendor / suppliers
• Assemble the vendor / supplier reference
• Evaluate each reference architecture based on the constraints / requirements list
• Look for synergies and commonalities among architectures. Consider future integration points

Master Data Management (MDM) – A phased Approach.

By definition of Wikipedia, “ In business, master data management (MDM) comprises the processes, governance, polices, standards and tools that consistently define and manage the critical data of an organization to provide a single point of reference. Master data management has the objectives of providing processes for collecting, aggregating, matching, consolidating, quality-assuring, persisting and distributing such data throughout an organization to ensure consistency and control in the ongoing maintenance and application use of this information.”

The article “Supporting Your Data Management Strategy with a Phased Approach to Master Data management” by SAS brings some interesting points and provides some development approach.

We often talk about the MDM is to create a central repository of data or the master date to provide an organization a single point of reference. But the article argues that “If the goal of master data management is to integrate business value dependencies into a long-term information strategy, it is worthwhile to rethink both the intent – and potentially the value – of the concept of “master data.” Therefore, the focus must shift away from delivering master repositories. Organizations must transition the implementation from being technology-based and consolidation-focused to being value-based and consumption-focused. This more reasonable approach to the idea of master data is not creating a single source of truth but providing unobstructed access to a consistent representation of shared information.”

This article also provides a phased approach to MDM, this approach can influence a phased organizational plan for fully embracing master data management. The plan incorporates five key fundamental techniques to enable master data management success, including:

•        Business data consumer engagement.

•        Data governance.

•        Collaborative semantic metadata management.

•        Data quality management.

•        Identity resolution and management.

In our organization we are developing master data management strategy, this article makes me rethink how we should develop strategy which can help to meet the business requirements. I think MDM not only needs to provide “a single point of truth” master data but it is also important to deliver the benefits of sharing consistent, high-quality data while aligning the milestone and deliverables of medium and long-term information strategy.

Reference

Supporting Your Data Management Strategy with a Phased Approach to Master Data management - SAS

https://en.wikipedia.org/wiki/Master_data_management

Data Strategy

Data Architecture describes how data is processed, stored, and utilized in a given system. Data architecture defines the types and sources of data needed to support the business, in a way that can be understood by stakeholders. One of the most important tasks that a Data Architect is often asked to help with is the creation of an Enterprise Data Strategy. The data strategy lays the foundation for the data and information architecture. 

Data and information is becoming more and more important as it will be an essential and integral part of future business models. Data and information from all over the enterprise, combined with data and information from external business partners and other sources needs to be managed. Big data initiatives will explore a huge amount of data to gain new insights with the objective to further optimize processes and decision making or create new services and business models.

The potentially disruptive shift driven by data and information centric initiatives opens up new markets and improvement potentials in many different domains including products, supply chain, manufacturing, production, sales and marketing, finance and accounting or research and development. Data and information and their “smart” management is one of the enablers for the digitization of organization.

“Top-performing organizations use data for competitive advantage and exploit more internal and external data. Technology doesn’t separate top performers from the rest of the pack; data governance and the alignment of data processes and business processes make the difference.” (Forrester Research, 2015)

The strategic recommendation is to have a joint approach of business and IT. The idea is to develop the data and information architecture with a professional data management and a flexible governance organization together with concrete use cases. This effort will generate sustainable business value and prepare the data and information landscape for future demands.

The Enterprise Data Strategy is:

·       Actionable

·       Relevant (e.g. contextual to the organization, not generic)

·       Evolutionary (e.g. it is expected to change on a regular basis)

·       Connected / Integrated – with everything that comes after it or from it

Reference

http://dataconomy.com/why-organizations-need-a-data-strategy/

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

https://www.cloudera.com/content/dam/cloudera/Resources/PDF/Reports/TDWI-Best-Practices-Report_Hadoop-for-the-Enterprise.pdf

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.