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.