Tag Archives: integration

It Is a Big World for Big Data After All

By E.G. Nadhan, HP

In the Information Week Global CIO blog, Patrick Houston says that big is bad when it comes to data, questioning the appropriateness of the term big data. Houston highlights the risk of the term being taken literally by the not-so-technical folks. Big data will continue to spread with emerging associative terms like big data expertbig data technologies, etc. I also see other reactions to this term like the one in Allison Watterson’s post, “What do you mean big data, little data is hard enough.” So why has it gained this broad adoption so fast?

Here are my top 5 reasons why the term big data has stuck, and why it may be appropriate, after all:

Foundational. It all started with data processing going decades back. Over the years, we have seen:

  • Big Computer – monolithic behemoths – or in today’s terms, legacy platforms
  • Big Network – local and wide area networks
  • Big Connector – the Internet that facilitated meaningful access with a purpose to consumers across the globe
  • Big Communicator – social media that has fostered communication beyond our imagination

It is all leading up to the generation and consumption of big data driven by presence. It was all about data to start with, and we have come back full circle to data again.

PervasiveBig Data will pervasively promote a holistic approach across all architectural elements of cloud computing:

  • Compute – complex data processing algorithms
  • Network – timely transmission of high volumes of data
  • Storage – various media to house <choose your prefix> bytes of data

FamiliarBig is always part of compound associations whether it be a hamburger (Big Mac), Big Brother or The Big Dipper. It is a big deal, shall we say? Data has always been generated and consumed with continued emergence of evolutionary technologies. You say big data and pictures of data rapidly growing like a balloon or spreading like water come to mind. It has something to do with data. There is something big about it.

Synthetic. Thomas C. Redman introduces a term “Informationlization” in the Harvard Business Review blog titled, “Integrate data into product, or get left behind.”  To me, the term big data is also about the synthesis individual pixels on the display device coming together to present a cohesive, meaningful picture.

Simple. You cannot get simpler than a three-letter word paired up with a four-letter word to mean something by itself. Especially when neither one is a TLA (three-letter acronym) for something very difficult to pronounce! Children in their elementary grades start learning these simple words before moving on to complex spelling bees with an abundance of vowels and y and x and q letters. Big data rolls off the tongue easily with a total of three syllables.

As humans, we tend to gravitate towards simplicity, which is why the whole world chimes in and sways back and forth when Sir Paul McCartney sings Hey Jude! decades after the first performance of this immortal piece. The line that sticks in our mind is the simplest line in the whole song – easy to render – one that we hum along with our hearts. Likewise, big data provides the most simplistic interpretation possible for a really complex world out there.

I actually like what Houston proposes – gushing data. However, I am not sure if it would enjoy the attention that big data gets. It represents a domain that needs to be addressed globally across all architectural layers by everyone including the consumers, administrators and orchestrators of data.

Therefore, big data is not just good enough – it is apt.

What about you? Do you have other names in mind? What does big data mean to you?

A version of this blog post originally appeared on the HP Enterprise Services Blog.

HP Distinguished Technologist and Cloud Advisor, E.G.Nadhan has over 25 years of experience in the IT industry across the complete spectrum of selling, delivering and managing enterprise level solutions for HP customers. He is the founding co-chair for The Open Group SOCCI project and is also the founding co-chair for the Open Group Cloud Computing Governance project. Twitter handle @NadhanAtHPwww.hp.com/go/journeyblog

2 Comments

Filed under Data management

Take a Lesson from History to Integrate to the Cloud

By E.G. Nadhan, HP

In an earlier post for The Open Group Blog on the Top 5 tell-tale signs of SOA evolving to the Cloud, I had outlined the various characteristics of SOA that serve as a foundation for the cloud computing paradigm.  Steady growth of service oriented practices and the continued adoption of cloud computing across enterprises has resulted in the need for integrating out to the cloud.  When doing so, we must take a look back in time at the evolution of integration solutions starting with point-to-point solutions maturing to integration brokers and enterprise services buses over the years.  We should take a lesson from history to ensure that this time around, when integrating to the cloud, we prevent undue proliferation of point-to-point solutions across the extended enterprise.

We must exercise the same due-diligence and governance as is done for services within the enterprise. There is an increased risk of point-to-point solutions proliferating because of consumerization of IT and the ease of availability of such services to individual business units.

Thus, here are 5 steps that need to be taken to ensure a more systemic approach when integrating to cloud-based service providers.

  1. Extend your SOA strategy to the Cloud. Review your current SOA strategy and extend this to accommodate cloud based as-a-service providers.
  2. Extend Governance around Cloud Services.   Review your existing IT governance and SOA governance processes to accommodate the introduction and adoption of cloud based as-a-service providers.
  3. Identify Cloud based Integration models. It is not a one-size fits all. Therefore multiple integration models could apply to the cloud-based service provider depending upon the enterprise integration architecture. These integration models include a) point-to-point solutions, b) cloud to on-premise ESB and c) cloud based connectors that adopt a service centric approach to integrate cloud providers to enterprise applications and/or other cloud providers.
  4. Apply right models for right scenarios. Review the scenarios involved and apply the right models to the right scenarios.
  5. Sustain and evolve your services taxonomy. Provide enterprise-wide visibility to the taxonomy of services – both on-premise and those identified for integration with the cloud-based service providers. Continuously evolve these services to integrate to a rationalized set of providers who cater to the integration needs of the enterprise in the cloud.

The biggest challenge enterprises have in driving this systemic adoption of cloud-based services comes from within its business units. Multiple business units may unknowingly avail the same services from the same providers in different ways. Therefore, enterprises must ensure that such point-to-point integrations do not proliferate like they did during the era preceding integration brokers.

Enterprises should not let history repeat itself when integrating to the cloud by adopting service-oriented principles.

How about your enterprise? How are you going about doing this? What is your approach to integrating to cloud service providers?

A version of this post was originally published on HP’s Enterprise Services Blog.

HP Distinguished Technologist and Cloud Advisor, E.G.Nadhan has over 25 years of experience in the IT industry across the complete spectrum of selling, delivering and managing enterprise level solutions for HP customers. He is the founding co-chair for The Open Group SOCCI project and is also the founding co-chair for the Open Group Cloud Computing Governance project. Twitter handle @NadhanAtHP.

1 Comment

Filed under Cloud, Cloud/SOA

Part 3 of 3: Building an Enterprise Architecture Value Proposition Using TOGAF® 9.1. and ArchiMate® 2.0

By Serge Thorn, Architecting the Enterprise

This is the third and final post in a three-part series by Serge Thorn. For more in this series, please see Part One and Part Two.

Value Management uses a combination of concepts and methods to create sustainable value for both organizations and their stakeholders. Some tools and techniques are specific to Value Management and others are generic tools that many organizations and individuals use. There exist many Value Management techniques such as cost-benefits analysis, SWOT analysis, value analysis, Pareto analysis, objectives hierarchy, function analysis system technique (FAST), and more…

The one I suggest to illustrate is close to the objectives hierarchy technique, which is a diagrammatic process for identifying objectives in a hierarchical manner and often used in conjunction with business functions. Close, because I will use a combination of the TOGAF® 9.1 metamodel with the ArchiMate® 2.0 Business Layer, Application Layer and Motivation Extensions Metamodels, consider core entities such as value, business goals, objectives, business processes and functions, business and application services, application functions and components. This approach was inspired by the presentation by Michael van den Dungen and Arjan Visser at The Open Group Conference in Amsterdam 2010, and here I’m also adding some ArchiMate 2.0 concepts.

First, the entities from the TOGAF 9.1 metamodel:

Then I will consider the entities from ArchiMate 2.0. Some may be identical to TOGAF 9.1. In the Business Layer, one key concept will obviously be the value. In this case I will consider the product (“A coherent collection of services, accompanied by a contract/set of agreements, which is offered as a whole to (internal or external) customers” according to ArchiMate 2.0), as the Enterprise Architecture program. In addition to that, I would refer to business services, functions, and processes.

In the Motivation Extension Metamodel, the goals. The objective entity in TOGAF 9.1 can also be represented using the concept of “goal.”

And in the Application Layer Metamodel, application services, functions, and components.

It is important to mention that when we deliver a value proposition, we must demonstrate to the business where the benefits will be with concrete examples. For example: the business sees Operational Excellence and Customer Intimacy as key drivers, and soon you will realize that BPM suites or CRM could support the business goals. These are the reasons why we consider the Application Layer Metamodel.

We could then use a combination of the ArchiMate 2.0 viewpoints such as: Stakeholder Viewpoint, Goal Realization Viewpoint, Motivation Viewpoint, or some other viewpoints to demonstrate the value of Enterprise Architecture for a specific business transformation program (or any other strategic initiative).

To be mentioned that the concept of benefit does not exist in any of the metamodels.

I have added the concept as an extension to ArchiMate in the following diagram which is the mapping of the value to a program related to the “improvement of customers’ relationships.” I also have intentionally limited the number of concepts or entities, such as processes, application services or measures.

Using these ArchiMate 2.0 modelling techniques can demonstrate to your stakeholders the value proposition for a business program, supported by an Enterprise Architecture initiative.

As a real example, if the expected key business benefit is operational excellence through process controls, which would represent a goal, you could present such a high level diagram to explain why application components like a BPM Suite could help (detecting fraud and errors, embedding preventive controls, continuously auditing and monitoring processes, and more).

There is definitely not a single way of demonstrating the value of Enterprise Architecture and you probably will have to adapt the process and the way you will present that value to all companies you will be working with. Without a doubt Enterprise Architecture contributes to the success of an organization and brings numerous benefits, but very often it needs to be able to demonstrate that value. Using some techniques as described previously will help to justify such an initiative.

The next steps will be the development of measures, metrics and KPIs to continuously monitor that value proposition.

Serge Thorn is CIO of Architecting the Enterprise.  He has worked in the IT Industry for over 25 years, in a variety of roles, which include; Development and Systems Design, Project Management, Business Analysis, IT Operations, IT Management, IT Strategy, Research and Innovation, IT Governance, Architecture and Service Management (ITIL). He is the Chairman of the itSMF (IT Service Management forum) Swiss chapter and is based in Geneva, Switzerland.

Comments Off

Filed under ArchiMate®, Enterprise Architecture, Enterprise Transformation, TOGAF®

Part 2 of 3: Building an Enterprise Architecture Value Proposition Using TOGAF® 9.1. and ArchiMate® 2.0

By Serge Thorn, Architecting the Enterprise

This is the second post in a three-part series by Serge Thorn.

Continuing from Part One of this series, here are more examples of what an enterprise cannot achieve without Enterprise Architecture:

Reduce IT costs by consolidating, standardizing, rationalizing and integrating corporate information systems

Cost avoidance can be achieved by identifying overlapping functional scope of two or more proposed projects in an organization or the potential cost savings of IT support by standardizing on one solution.

Consolidation can happen at various levels for architectures — for shared enterprise services, applications and information, for technologies and even data centers.

This could involve consolidating the number of database servers, application or web servers and storage devices, consolidating redundant security platforms, or adopting virtualization, grid computing and related consolidation initiatives. Consolidation may be a by-product of another technology transformation or it may be the driver of these transformations.

Whatever motivates the change, the key is to be in alignment, once again, with the overall business strategy. Enterprise architects understand where the business is going, so they can pick the appropriate consolidation strategy. Rationalization, standardization and consolidation processes helps organizations understand their current enterprise maturity level and move forward on the appropriate roadmap.

More spending on innovation

Enterprise Architecture should serve as a driver of innovation. Innovation is highly important when developing a target Enterprise Architecture and in realizing the organization’s strategic goals and objectives. For example, it may help to connect the dots between business requirements and the new approaches SOA and cloud services can deliver.

Enabling strategic business goals via better operational excellence

Building Enterprise Architecture defines the structure and operation of an organization. The intent of Enterprise Architecture is to determine how an organization can most effectively achieve its current and future objectives. It must be designed to support an organization’s specific business strategies.

Jeanne W. Ross, Peter Weill, David C. Robertson in “Enterprise Architecture as Strategy: Creating a Foundation for Business” wrote “Companies with more-mature architectures reported greater success in achieving strategic goals” (p. 89). “This included better operational excellence, more customer intimacy, and greater product leadership” (p. 100).

Customer intimacy

Enterprises that are customer focused and aim to provide solutions for their customers should design their business model, IT systems and operational activities to support this strategy at the process level. This involves the selection of one or few high-value customer niches, followed by an obsessive effort at getting to know these customers in detail.

Greater product leadership

This approach enabled by Enterprise Architecture is dedicated to providing the best possible products from the perspective of the features and benefits offered to the customer. It is the basic philosophy about products that push performance boundaries. Products or services delivered by the business will be refined by leveraging IT to do the end customer’s job better. This will be accomplished by the delivery of new business capabilities (e.g. on-line websites, BI, etc.).

Comply with regulatory requirements

Enterprise Architecture helps companies to know and represent their processes and systems and how they correlate. This is fundamental for risk management and managing regulation requirements, such as those derived from Sarbanes-Oxley, COSO, HIPAA, etc.

This list could be continued as there are many other reasons why Enterprise Architecture brings benefits to organizations. Once your benefits have been documented you could also consider some value management techniques. TOGAF® 9.1 refers in the Architecture Vision phase to a target value proposition for a specific project.  In the next blog, we’ll address the issue of applying the value proposition to the Enterprise Architecture initiative as a whole.

The third and final part of this blog series will discuss value management. 

Serge Thorn is CIO of Architecting the Enterprise.  He has worked in the IT Industry for over 25 years, in a variety of roles, which include; Development and Systems Design, Project Management, Business Analysis, IT Operations, IT Management, IT Strategy, Research and Innovation, IT Governance, Architecture and Service Management (ITIL). He is the Chairman of the itSMF (IT Service Management forum) Swiss chapter and is based in Geneva, Switzerland.

2 Comments

Filed under ArchiMate®, Enterprise Architecture, Enterprise Transformation, TOGAF®

Part 1 of 3: Building an Enterprise Architecture Value Proposition Using TOGAF® 9.1. and ArchiMate® 2.0

By Serge Thorn, Architecting the Enterprise

This is the first post in a three-part series by Serge Thorn. 

When introducing Enterprise Architecture as a program or initiative, it is regularly done from an IT perspective rarely considering what the costs will be and if there will be any return on investment. This presents a particular challenge to Enterprise Architecture.

Generally speaking, IT departments have all sorts of criteria to justify projects and measure their performance. They use measurements, metrics and KPIs. Going to the solution level, they commonly use indicators such as percentage uptime for systems from the system management team, error rates for applications from the development support team or number of calls resolved on the first call from the service desk, etc. These KPIs usually are defined at an early stage and very often delivered in dashboards from various support applications.

On the other hand, it is much more difficult to define and implement a quantifiable measure for Enterprise Architecture. Many activities introduced with appropriate governance will enhance the quality of the delivered products and services, but it still will be a challenge to attribute results to the quality of Enterprise Architecture efforts.

This being said, Enterprise Architects should be able to define and justify the benefits of their activities to their stakeholders, and to help executives understand how Enterprise Architecture will contribute to the primary value-adding objectives and processes, before starting the voyage. The more it is described and understood, the more the Enterprise Architecture team will gain support from the management. There are plenty of contributions that Enterprise Architecture brings and they will have to be documented and presented at an early stage.

There won’t be just one single answer to demonstrate the value of an Enterprise Architecture but there seems to be a common pattern when considering feedback from various companies I have worked with.

Without Enterprise Architecture you can probably NOT fully achieve:

IT alignment with the business goals

As an example among others, the problem with most IT plans is that they do not indicate what the business value is and what strategic or tactical business benefit the organization is planning to achieve. The simple matter is that any IT plan needs also to have a business metric, not only an IT metric of delivery. Another aspect is the ability to create and share a common vision of the future shared by the business and IT communities.

Integration

With the rapid pace of change in business environment, the need to transform organizations into agile enterprises that can respond quickly to change has never been greater. Methodologies and computer technologies are needed to enable rapid business and system change. The solution also lies in enterprise integration (both business and technology integration).

For business integration, we use Enterprise Architecture methodologies and frameworks to integrate functions, processes, data, locations, people, events and business plans throughout an organization. Specifically, the unification and integration of business processes and data across the enterprise and potential linkage with external partners become more and more important.

To also have technology integration, we may use enterprise portals, enterprise application integration (EAI/ESB), web services, service-oriented architecture (SOA), business process management (BPM) and try to lower the number of interfaces.

Change management

In recent years the scope of Enterprise Architecture has expanded beyond the IT domain and enterprise architects are increasingly taking on broader roles relating to organizational strategy and change management. Frameworks such as TOGAF® 9.1 include processes and tools for managing both the business/people and the technology sides of an organization. Enterprise Architecture supports the creation of changes related to the various architecture domains, evaluating the impact on the enterprise, taking into account risk management, financial aspects (cost/benefit analysis), and most importantly ensuring alignment with business goals and objectives. Enterprise Architecture value is essentially tied to its ability to help companies to deal with complexity and changes.

Reduced time to market and increased IT responsiveness

Enterprise Architecture should reduce systems development, applications generation and modernization timeframes for legacy systems. It should also decrease resource requirements. All of this can be accomplished by re-using standards or existing components, such as the architecture and solution building blocks in TOGAF 9.1. Delivery time and design/development costs can also be decreased by the reuse of reference models. All that information should be managed in an Enterprise Architecture repository.

Better access to information across applications and improved interoperability

Data and information architectures manage the organization assets of information, optimally and efficiently. This supports the quality, accuracy and timely availability of data for executive and strategic business decision-making, across applications.

Readily available descriptive representations and documentation of the enterprise

Architecture is also a set of descriptive representations (i.e. “models”) that are relevant for describing an enterprise such that it can be produced to management’s requirements and maintained over the period of its useful life. Using an architecture repository, developing a variety of artifacts and modelling some of the key elements of the enterprise, will contribute to build this documentation.

The second part of the series will include more examples of what an enterprise cannot achieve without Enterprise Architecture. 

Serge Thorn is CIO of Architecting the Enterprise.  He has worked in the IT Industry for over 25 years, in a variety of roles, which include; Development and Systems Design, Project Management, Business Analysis, IT Operations, IT Management, IT Strategy, Research and Innovation, IT Governance, Architecture and Service Management (ITIL). He is the Chairman of the itSMF (IT Service Management forum) Swiss chapter and is based in Geneva, Switzerland.

3 Comments

Filed under ArchiMate®, Enterprise Architecture, Enterprise Transformation, TOGAF®