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