Tag Archives: enterprise

Big Data Security Tweet Jam

By Patty Donovan, The Open Group

On Tuesday, January 22, The Open Group will host a tweet jam examining the topic of Big Data and its impact on the security landscape.

Recently, Big Data has been dominating the headlines, analyzing everything about the topic from how to manage and process it, to the way it will impact your organization’s IT roadmap. As 2012 came to a close, analyst firm, Gartner predicted that data will help drive IT spending to $3.8 trillion in 2014. Knowing the phenomenon is here to stay, enterprises face a new and daunting challenge of how to secure Big Data. Big Data security also raises other questions, such as: Is Big Data security different from data security? How will enterprises handle Big Data security? What is the best approach to Big Data security?

It’s yet to be seen if Big Data will necessarily revolutionize enterprise security, but it certainly will change execution – if it hasn’t already. Please join us for our upcoming Big Data Security tweet jam where leading security experts will discuss the merits of Big Data security.

Please join us on Tuesday, January 22 at 9:00 a.m. PT/12:00 p.m. ET/5:00 p.m. GMT for a tweet jam, moderated by Dana Gardner (@Dana_Gardner), ZDNet – Briefings Direct, that will discuss and debate the issues around big data security. Key areas that will be addressed during the discussion include: data security, privacy, compliance, security ethics and, of course, Big Data. We welcome Open Group members and interested participants from all backgrounds to join the session and interact with our panel of IT security experts, analysts and thought leaders led by Jim Hietala (@jim_hietala) and Dave Lounsbury (@Technodad) of The Open Group. To access the discussion, please follow the #ogChat hashtag during the allotted discussion time.

And for those of you who are unfamiliar with tweet jams, here is some background information:

What Is a Tweet Jam?

A tweet jam is a one hour “discussion” hosted on Twitter. The purpose of the tweet jam is to share knowledge and answer questions on Big Data security. Each tweet jam is led by a moderator and a dedicated group of experts to keep the discussion flowing. The public (or anyone using Twitter interested in the topic) is encouraged to join the discussion.

Participation Guidance

Whether you’re a newbie or veteran Twitter user, here are a few tips to keep in mind:

  • Have your first #ogChat tweet be a self-introduction: name, affiliation, occupation.
  • Start all other tweets with the question number you’re responding to and the #ogChat hashtag.
    • Sample: “Q1 enterprises will have to make significant adjustments moving forward to secure Big Data environments #ogChat”
    • Please refrain from product or service promotions. The goal of a tweet jam is to encourage an exchange of knowledge and stimulate discussion.
    • While this is a professional get-together, we don’t have to be stiff! Informality will not be an issue!
    • A tweet jam is akin to a public forum, panel discussion or Town Hall meeting – let’s be focused and thoughtful.

If you have any questions prior to the event or would like to join as a participant, please direct them to Rod McLeod (rmcleod at bateman-group dot com). We anticipate a lively chat and hope you will be able to join!

 

patricia donovanPatricia Donovan is Vice President, Membership & Events, at The Open Group and a member of its executive management team. In this role she is involved in determining the company’s strategic direction and policy as well as the overall management of that business area. Patricia joined The Open Group in 1988 and has played a key role in the organization’s evolution, development and growth since then. She also oversees the company’s marketing, conferences and member meetings. She is based in the U.S.

1 Comment

Filed under Tweet Jam

The Death of Planning

By Stuart Boardman, KPN

If I were to announce that planning large scale transformation projects was a waste of time, you’d probably think I’d taken leave of my senses. And yet, somehow this thought has been nagging at me for some time now. Bear with me.

It’s not so long ago that we still had debates about whether complex projects should be delivered as a “big bang” or in phases. These days the big bang has pretty much been forgotten. Why is that? I think the main reason is the level of risk involved with running a long process and dropping it into the operational environment just like that. This applies to any significant change, whether related to a business model and processes or IT architecture or physical building developments. Even if it all works properly, the level of sudden organizational change involved may stop it in its tracks.

So it has become normal to plan the change as a series of phases. We develop a roadmap to get us from here (as-is) to the end goal (to-be). And this is where I begin to identify the problem.

A few months ago I spent an enjoyable and thought provoking day with Jack Martin Leith (@jackmartinleith). Jack is a master in demystifying clichés but when he announced his irritation with “change is a journey,” I could only respond, “but Jack, it is.” What Jack made me see is that, whilst the original usage was a useful insight, it’s become a cliché which is commonly completely misused. It results in some pretty frustrating journeys! To understand that let’s take the analogy literally. Suppose your objective is to travel to San Diego but there are no direct flights from where you live. If the first step on your journey is a 4 hour layover at JFK, that’s at best a waste of your time and energy. There’s no value in this step. A day in Manhattan might be a different story. We can (and do) deal with this kind of thing for journeys of a day or so but imagine a journey that takes three or more years and all you see on the way is the inside of airports.

My experience has been that the same problem too often manifests itself in transformation programs. The first step may be logical from an implementation perspective, but it delivers no discernible value (tangible or intangible). It’s simply a validation that something has been done, as if, in our travel analogy, we were celebrating travelling the first 1000 kilometers, even if that put us somewhere over the middle of Lake Erie.

What would be better? An obvious conclusion that many have drawn is that we need to ensure every step delivers business value but that’s easier said than done.

Why is it so hard? The next thing Jack said helped me understand why. His point is that when you’ve taken the first step on your journey, it’s not just some intermediate station. It’s the “new now.” The new reality. The new as-is. And if the new reality is hanging around in some grotty airport trying to do your job via a Wi-Fi connection of dubious security and spending too much money on coffee and cookies…….you get the picture.

The problem with identifying that business value is that we’re not focusing on the new now but on something much more long-term. We’re trying to interpolate the near term business value out of the long term goal, which wasn’t defined based on near term needs.

What makes this all the more urgent is the increasing rate and unpredictability of change – in all aspects of doing business. This has led us to shorter planning horizons and an increasing tendency to regard that “to be” as nothing more than a general sense of direction. We’re thinking, “If we could deliver the whole thing really, really quickly on the basis of what we know we’d like to be able to do now, if it were possible, then it would look like this” – but knowing all the time that by the time we get anywhere near that end goal, it will have changed. It’s pretty obvious then that a first step, whose justification is entirely based on that imagined end goal, can easily be of extremely limited value.

So why not put more focus on the first step? That’s going to be the “new now.” How about making that our real target? Something that the enterprise sees as real value and that is actually feasible in a reasonable time scale (whatever that is). Instead of scoping that step as an intermediate (and rather immature) layover, why not put all our efforts into making it something really good? And when we get there and people know how the new now looks and feels, we can all think afresh about where to go next. After all, a journey is not simply defined by its destination but by how you get there and what you see and do on the way. If the actual journey itself is valuable, we may not want to get to the end of it.

Now that doesn’t mean we have to forget all about where we might want to be in three or even five years — not at all. The long term view is still important in helping us to make smart decisions about shorter term changes. It helps us allow for future change, even if only because it lets us see how much might change. And that helps us make sound decisions. But we should accept that our three or five year horizon needs to be continually open to revision – not on some artificial yearly cycle but every time there’s a “new now.” And this needs to include the times where the new now is not something we planned but is an emergent development from within or outside of the enterprise or is due to a major regulatory or market change.

So, if the focus is all on the first step and if our innovation cycle is getting steadily shorter, what’s the value of planning anything? Relax, I’m not about to fire the entire planning profession. If you don’t plan how you’re going to do something, what your dependencies are, how to react to the unexpected, etc., you’re unlikely to achieve your goal at all. Arguably that’s just project planning.

What about program planning? Well, if the program is so exposed to change maybe our concept of program planning needs to change. Instead of the plan being a thing fixed in stone that dictates everything, it could become a process in which the whole enterprise participates – itself open to emergence. The more I think about it, the more appealing that idea seems.

In my next post, I’ll go into more detail about how this might work, in particular from the perspective of Enterprise Architecture. I’ll also look more at how “the new planning” relates to innovation, emergence and social business and at the conflicts and synergies between these concerns. In the meantime, feel free to throw stones and see where the story doesn’t hold up.

Stuart Boardman is a Senior Business Consultant with KPN where he co-leads the Enterprise Architecture practice as well as the Cloud Computing solutions group. He is co-lead of The Open Group Cloud Computing Work Group’s Security for the Cloud and SOA project and a founding member of both The Open Group Cloud Computing Work Group and The Open Group SOA Work Group. Stuart is the author of publications by the Information Security Platform (PvIB) in The Netherlands and of his previous employer, CGI. He is a frequent speaker at conferences on the topics of Cloud, SOA, and Identity. 

7 Comments

Filed under Enterprise Architecture, Uncategorized

Flying in the Cloud by the Seat of Our Pants

By Chris Harding, The Open Group

In the early days of aviation, when instruments were unreliable or non-existent, pilots often had to make judgments by instinct. This was known as “flying by the seat of your pants.” It was exciting, but error prone, and accidents were frequent. Today, enterprises are in that position with Cloud Computing.

Staying On Course

Flight navigation does not end with programming the flight plan. The navigator must check throughout the flight that the plane is on course.  Successful use of Cloud requires, not only an understanding of what it can do for the business, but also continuous monitoring that it is delivering value as expected. A change of service-level, for example, can have as much effect on a user enterprise as a change of wind speed on an aircraft.

The Open Group conducted a Cloud Return on Investment (ROI) survey in 2011. Then, 55 percent of those surveyed felt that Cloud ROI would be easy to evaluate and justify, although only 35 percent had mechanisms in place to do it. When we repeated the survey in 2012, we found that the proportion that thought it would be easy had gone down to 44 percent, and only 20 percent had mechanisms in place. This shows, arguably, more realism, but it certainly doesn’t show any increased tendency to monitor the value delivered by Cloud. In fact, it shows the reverse. The enterprise pilots are flying by the seats of their pants. (The full survey results are available at http://www.opengroup.org/sites/default/files/contentimages/Documents/cloud_roi_formal_report_12_19_12-1.pdf)

They Have No Instruments

It is hard to blame the pilots for this, because they really do not have the instruments. The Open Group published a book in 2011, Cloud Computing for Business, that explains how to evaluate and monitor Cloud risk and ROI, with spreadsheet examples. The spreadsheet is pretty much the state-of-the-art in Cloud ROI instrumentation.  Like a compass, it is robust and functional at a basic level, but it does not have the sophistication and accuracy of a satellite navigation system. If we want better navigation, we must have better systems.

There is scope for Enterprise Architecture tool vendors to fill this need. As the inclusion of Cloud in Enterprise Architectures becomes commonplace, and Cloud Computing metrics and their relation to ROI become better understood, it should be possible to develop the financial components of Enterprise Architecture modeling tools so that the business impact of the Cloud systems can be seen more clearly.

The Enterprise Flight Crew

But this is not just down to the architects. The architecture is translated into systems by developers, and the systems are operated by operations staff. All of these people must be involved in the procurement and configuration of Cloud services and their monitoring through the Cloud buyers’ life cycle.

Cloud is already bringing development and operations closer together. The concept of DevOps, a paradigm that stresses communication, collaboration and integration between software developers and IT operations professionals, is increasingly being adopted by enterprises that use Cloud Computing. This communication, collaboration and integration must involve – indeed must start with – enterprise architects, and it must include the establishment and monitoring of Cloud ROI models. All of these professionals must co-operate to ensure that the Cloud-enabled enterprise keeps to its financial course.

The Architect as Pilot

The TOGAF® architecture development method includes a phase (Phase G) in which the architects participate in implementation governance. The following Phase H is currently devoted to architecture change management, with the objectives of ensuring that the architecture lifecycle is maintained, the architecture governance framework is executed, and the Enterprise Architecture capability meets current requirements. Perhaps Cloud architects should also think about ensuring that the system meets its business requirements, and continues to do so throughout its operation. They can then revisit earlier phases of the architecture development cycle (always a possibility in TOGAF) if it does not.

Flying the Cloud

Cloud Computing compresses the development lifecycle, cutting the time to market of new products and the time to operation of new enterprise systems. This is a huge benefit. It implies closer integration of architecture, development and operations. But this must be supported by proper instrumentation of the financial parameters of Cloud services, so that the architecture, development and operations professionals can keep the enterprise on course.

Flying by the seat of the pants must have been a great experience for the magnificent men in the flying machines of days gone by, but no one would think of taking that risk with the lives of 500 passengers on a modern aircraft. The business managers of a modern enterprise should not have to take that risk either. We must develop standard Cloud metrics and ROI models, so that they can have instruments to measure success.

Dr. Chris Harding is Director for Interoperability and SOA at The Open Group. He has been with The Open Group for more than ten years, and is currently responsible for managing and supporting its work on interoperability, including SOA and interoperability aspects of Cloud Computing. He is a member of the BCS, the IEEE and the AEA, and is a certified TOGAF practitioner.

10 Comments

Filed under Cloud/SOA

2013 Open Group Predictions, Vol. 1

By The Open Group

A big thank you to all of our members and staff who have made 2012 another great year for The Open Group. There were many notable achievements this year, including the release of ArchiMate 2.0, the launch of the Future Airborne Capability Environment (FACE™) Technical Standard and the publication of the SOA Reference Architecture (SOA RA) and the Service-Oriented Cloud Computing Infrastructure Framework (SOCCI).

As we wrap up 2012, we couldn’t help but look towards what is to come in 2013 for The Open Group and the industries we‘re a part of. Without further ado, here they are:

Big Data
By Dave Lounsbury, Chief Technical Officer

Big Data is on top of everyone’s mind these days. Consumerization, mobile smart devices, and expanding retail and sensor networks are generating massive amounts of data on behavior, environment, location, buying patterns – etc. – producing what is being called “Big Data”. In addition, as the use of personal devices and social networks continue to gain popularity so does the expectation to have access to such data and the computational power to use it anytime, anywhere. Organizations will turn to IT to restructure its services so it meets the growing expectation of control and access to data.

Organizations must embrace Big Data to drive their decision-making and to provide the optimal service mix services to customers. Big Data is becoming so big that the big challenge is how to use it to make timely decisions. IT naturally focuses on collecting data so Big Data itself is not an issue.. To allow humans to keep on top of this flood of data, industry will need to move away from programming computers for storing and processing data to teaching computers how to assess large amounts of uncorrelated data and draw inferences from this data on their own. We also need to start thinking about the skills that people need in the IT world to not only handle Big Data, but to make it actionable. Do we need “Data Architects” and if so, what would their role be?

In 2013, we will see the beginning of the Intellectual Computing era. IT will play an essential role in this new era and will need to help enterprises look at uncorrelated data to find the answer.

Security

By Jim Hietala, Vice President of Security

As 2012 comes to a close, some of the big developments in security over the past year include:

  • Continuation of hacktivism attacks.
  • Increase of significant and persistent threats targeting government and large enterprises. The notable U.S. National Strategy for Trusted Identities in Cyberspace started to make progress in the second half of the year in terms of industry and government movement to address fundamental security issues.
  • Security breaches were discovered by third parties, where the organizations affected had no idea that they were breached. Data from the 2012 Verizon report suggests that 92 percent of companies breached were notified by a third party.
  • Acknowledgement from senior U.S. cybersecurity professionals that organizations fall into two groups: those that know they’ve been penetrated, and those that have been penetrated, but don’t yet know it.

In 2013, we’ll no doubt see more of the same on the attack front, plus increased focus on mobile attack vectors. We’ll also see more focus on detective security controls, reflecting greater awareness of the threat and on the reality that many large organizations have already been penetrated, and therefore responding appropriately requires far more attention on detection and incident response.

We’ll also likely see the U.S. move forward with cybersecurity guidance from the executive branch, in the form of a Presidential directive. New national cybersecurity legislation seemed to come close to happening in 2012, and when it failed to become a reality, there were many indications that the administration would make something happen by executive order.

Enterprise Architecture

By Leonard Fehskens, Vice President of Skills and Capabilities

Preparatory to my looking back at 2012 and forward to 2013, I reviewed what I wrote last year about 2011 and 2012.

Probably the most significant thing from my perspective is that so little has changed. In fact, I think in many respects the confusion about what Enterprise Architecture (EA) and Business Architecture are about has gotten worse.

The stress within the EA community as both the demands being placed on it and the diversity of opinion within it increase continues to grow.  This year, I saw a lot more concern about the value proposition for EA, but not a lot of (read “almost no”) convergence on what that value proposition is.

Last year I wrote “As I expected at this time last year, the conventional wisdom about Enterprise Architecture continues to spin its wheels.”  No need to change a word of that. What little progress at the leading edge was made in 2011 seems to have had no effect in 2012. I think this is largely a consequence of the dust thrown in the eyes of the community by the ascendance of the concept of “Business Architecture,” which is still struggling to define itself.  Business Architecture seems to me to have supplanted last year’s infatuation with “enterprise transformation” as the means of compensating for the EA community’s entrenched IT-centric perspective.

I think this trend and the quest for a value proposition are symptomatic of the same thing — the urgent need for Enterprise Architecture to make its case to its stakeholder community, especially to the people who are paying the bills. Something I saw in 2011 that became almost epidemic in 2012 is conflation — the inclusion under the Enterprise Architecture umbrella of nearly anything with the slightest taste of “business” to it. This has had the unfortunate effect of further obscuring the unique contribution of Enterprise Architecture, which is to bring architectural thinking to bear on the design of human enterprise.

So, while I’m not quite mired in the slough of despond, I am discouraged by the community’s inability to advance the state of the art. In a private communication to some colleagues I wrote, “the conventional wisdom on EA is at about the same state of maturity as 14th century cosmology. It is obvious to even the most casual observer that the earth is both flat and the center of the universe. We debate what happens when you fall off the edge of the Earth, and is the flat earth carried on the back of a turtle or an elephant?  Does the walking of the turtle or elephant rotate the crystalline sphere of the heavens, or does the rotation of the sphere require the turtlephant to walk to keep the earth level?  These are obviously the questions we need to answer.”

Cloud

By Chris Harding, Director of Interoperability

2012 has seen the establishment of Cloud Computing as a mainstream resource for enterprise architects and the emergence of Big Data as the latest hot topic, likely to be mainstream for the future. Meanwhile, Service-Oriented Architecture (SOA) has kept its position as an architectural style of choice for delivering distributed solutions, and the move to ever more powerful mobile devices continues. These trends have been reflected in the activities of our Cloud Computing Work Group and in the continuing support by members of our SOA work.

The use of Cloud, Mobile Computing, and Big Data to deliver on-line systems that are available anywhere at any time is setting a new norm for customer expectations. In 2013, we will see the development of Enterprise Architecture practice to ensure the consistent delivery of these systems by IT professionals, and to support the evolution of creative new computing solutions.

IT systems are there to enable the business to operate more effectively. Customers expect constant on-line access through mobile and other devices. Business organizations work better when they focus on their core capabilities, and let external service providers take care of the rest. On-line data is a huge resource, so far largely untapped. Distributed, Cloud-enabled systems, using Big Data, and architected on service-oriented principles, are the best enablers of effective business operations. There will be a convergence of SOA, Mobility, Cloud Computing, and Big Data as they are seen from the overall perspective of the enterprise architect.

Within The Open Group, the SOA and Cloud Work Groups will continue their individual work, and will collaborate with other forums and work groups, and with outside organizations, to foster the convergence of IT disciplines for distributed computing.

3 Comments

Filed under Business Architecture, Cloud, Cloud/SOA, Cybersecurity, Enterprise Architecture

Different Words Meant Different Things, Part 3

By Leonard Fehskens, The Open Group

In the second part of this series, I examined the effect of our definition of enterprise on how we think about EA.

To close, I’ll consider the implications of a more inclusive concept of enterprise on the future of Enterprise Architecture.

The current cohort of EAs who have grown accustomed to a misnamed and narrowly focused discipline will eventually retire.  They will be replaced, over time, by EAs who learn the discipline in academic programs rather than by making it up on the job.  They will chuckle in amusement at a “body of knowledge” that is like that of medicine before germ theory, geology before plate tectonics, or astronomy before heliocentrism.  These programs are being created now, and academics are not interested in teaching a discipline with an irrational and inconsistent vocabulary.  They don’t want to have to explain to their students that it is for “historical reasons” that “enterprise means the IT part of a business.”

The focus of an academic program on Enterprise Architecture will necessarily reflect the prevailing concept of enterprise.  The commonly used model of Enterprise Architecture being about people, process and technology provides a useful context for considering this influence.

An IT-centric concept of Enterprise Architecture, like the one currently espoused by most of the community, will emphasize the role of information technology in supporting the needs of the business.  It will include just enough about business and people to enable practitioners to address the goal of “aligning IT with the business.”

A concept of Enterprise Architecture based on the idea of enterprise as business will emphasize business, especially business processes, as they are the primary locus of technological support.  It will include just enough about information technology and people to enable practitioners to address the goal of making IT a strategic asset for businesses.

A concept of Enterprise Architecture based on the idea of enterprise as human endeavor will emphasize the role of people, and be built around the sociology and psychology of individuals, groups and organizations, especially leadership and management as means to achieving organizational goals.  It will devote some attention to business as a particular kind of enterprise, but will look at other forms of enterprise and their unique concerns as well.  Finally, it will consider technology in its most general sense as the means of instantiating the infrastructure necessary to realize an enterprise.  There will be a lot of harumphing about how the conventional wisdom is correct by definition because it is what is practiced by the majority of practitioners, but there is a noisy and insistent contingent that will continue to point out that the world is not flat and the sun does not go around the earth.  Only time will tell, but however you measure it, over 90% of most organizations is “not-IT”, and the IT-centric perspective is simply so imbalanced that it can’t ultimately prevail.

Adopting a broader concept of enterprise consistent with its meaning in common English usage does not in any way invalidate any of the current applications or interpretations of Enterprise Architecture.  It simply allows the application of architectural thinking to other kinds of purposeful human activity besides commercial business organizations to be subsumed under the rubric “Enterprise Architecture”.  All entities that are enterprises by these more restrictive definitions clearly fit unchanged into this more inclusive definition of enterprise.

 Len Fehskens is Vice President of Skills and Capabilities at The Open GroupHe is responsible for The Open Group’s activities relating to the professionalization of the discipline of enterprise architecture. Prior to joining The Open Group, Len led the Worldwide Architecture Profession Office for HP Services at Hewlett-Packard. He majored in Computer Science at MIT, and has over 40 years of experience in the IT business as both an individual contributor and a manager, within both product engineering and services business units. Len has worked for Digital Equipment Corporation, Data General Corporation, Prime Computer, Compaq and Hewlett Packard.  He is the lead inventor on six software patents on the object oriented management of distributed systems.

12 Comments

Filed under Business Architecture, Enterprise Architecture

Different Words Mean Different Things, Part 2

By Leonard Fehskens, The Open Group

In the first part of this series, I proposed distinct meanings of enterprise, business, organization and corporation.

As I noted earlier, you don’t have to agree with the distinctions I am making here.  But words are a finite, “nonrenewable” resource – if you treat these four words as interchangeable synonyms, you will not be able to make these distinctions without finding other words to make them for you.  In particular, you will not be able to distinguish an endeavor from the means of realizing it (similar to confusing an architecture and a blueprint).  You will not be able to distinguish one particular kind of endeavor (for example, a commercial endeavor) from other kinds of endeavors.  You will not be able to distinguish one particular kind of organization from other kinds of organizations.

Treating these four words as synonyms makes these words unavailable to describe larger and more inclusive domains for the application of architectural thinking.  What’s more, it does so needlessly.  This discipline doesn’t need synonyms any more than an organization needs multiple different systems that do the same thing.  Synonyms are redundancies that reduce the expressive power of the language we use to talk about what we do.  We need to be able to make distinctions between things that are important to distinguish from one another, and there are only so many words available to us to do so.

I acknowledge that for most of the community of practicing business and enterprise architects, most if not all of their practice occurs in the context of business-as-commercial-entities.  It is therefore not surprising that many people in the Business and Enterprise Architecture communities would not believe these distinctions are worth making, and be perfectly happy to (if not insistent that we) treat these words as synonyms.  But we have to be careful to avoid the example of the six blind men and the elephant, and being able to explain a predisposition to make these words synonymous doesn’t make it the right thing to do.

There’s even a contingent that insists that enterprise doesn’t just mean a commercial business organization, that it means a specific kind of commercial business organization, one that exceeds some critical threshold with respect to its scale, complexity, sophistication, ambition or consequence.  This is a bit like insisting that the implied “building” in “(building) architecture” means “commercial building”, or more specifically, “skyscraper.”

The problem with this concept of enterprise arises when one tries to specify the objective criteria by which one distinguishes a mere business from the bigger, more complex, more sophisticated, more ambitious or more consequential business that deserves to be called an enterprise.  It is certainly the case that the larger, more complex, more sophisticated, more ambitious and more consequential a commercial business organization is, the more likely architectural thinking will be necessary and beneficial.  But this observation about Enterprise Architecture does not mean that we ought to define enterprise to mean a large, complex, sophisticated, ambitious and consequential commercial business organization.

Why have so many naval vessels been named Enterprise?  Why was the Starship Enterprise from the Star Trek franchise so named, and why was this thought to be an appropriate name for the first space shuttle?  It was not because these vessels embodied some idea of a commercial business organization or because the word connoted a big, complex, sophisticated, ambitious or consequential business.  And surely if the latter had been the reason, there would be many lesser vessels named simply “Business”?

There are two significant consequences to basing Enterprise Architecture (EA) on a concept of enterprise that is limited to a particular kind of organization.  The first has to do with the applicability of the discipline, and the second has to do with how we educate enterprise architects.

If we restrict the definition of enterprise to a specific kind of purposeful activity, whether the criteria we use for this restriction are subjective or objective, we must either argue that architectural thinking is inapplicable to those purposeful activities that do not satisfy these restrictions, or we have to find a word to denote the larger class of purposeful activities to which architectural thinking applies, a class that includes both the restricted concept of enterprise and all other activities to which architectural thinking applies.

If enterprise means the same thing as commercial business organization, what do we call an entity that is not a commercial business organization (e.g., a church, a hospital, a government, or an army)?  Does Enterprise Architecture not apply to such endeavors because they are not created primarily to conduct business transactions?  What do we call organizations that are not businesses?  If we want to talk about an organization that is a business, why can’t we just use the compound “business organization”, which not only does not erase the distinction, it makes clear the relationship between the two?  Similarly, if we want to talk about an enterprise that is a business, as an enterprise, why can’t we just use the compound “business enterprise”?

Similarly, what should we call the architectural discipline that applies to human enterprise in general, and of which any more narrowly defined concept of Enterprise Architecture is necessarily a specialization?

Expanding definitions

The recent surge of interest in “Business Architecture” is, in my opinion, reflective of both the realization by the community that the historically IT-centric focus of Enterprise Architecture is unnecessarily circumscribed, and the lack of a systematic and internally consistent concept of Enterprise Architecture shared throughout that community.

There is a growing faction within the EA community that argues that most of Enterprise Architecture as practiced is actually enterprise IT architecture (EITA), and calling this practice EA is a misuse of the term.  Despite this, the widespread adoption of the egregiously oversimplified model of an enterprise as comprising “the business” and IT, and thus, Enterprise Architecture as comprising “Business Architecture” and “IT Architecture”, has led to the emergence of “Business Architecture” as a distinct if ill-defined concept.

It seems to me that many people consider Enterprise Architecture to be so hopelessly tainted by its historic IT-centricity that they view the best course to be allowing Enterprise Architecture to continue to be misused to mean EITA, and letting Business Architecture take its place as what EA “should have meant.”  I note in passing that there are some people who insist that EA “has always meant,” or at least “originally” meant, the architecture of the enterprise as a whole, but was hijacked by the IT community, though no one has been able to provide other than thirty year old recollections to support this assertion.

As I noted at the outset, I think Enterprise Architecture should encompass the application of architectural thinking to human endeavors of all kinds, not just those that are primarily business in nature, including, for example, governmental, military, religious, academic, or medical enterprises.  Yes, these endeavors all have some business aspects, but they are not what we normally call businesses, and calling the discipline “Business Architecture” almost unavoidably encourages us to overlook the architectural needs of such non-business-centric endeavors and focus instead on the needs of one specific kind of endeavor.

We have the words to name these things properly. We simply have to start doing so.

In part 3 of this series, I’ll consider the implications of a more inclusive concept of enterprise on the future of Enterprise Architecture.

 Len Fehskens is Vice President of Skills and Capabilities at The Open GroupHe is responsible for The Open Group’s activities relating to the professionalization of the discipline of enterprise architecture. Prior to joining The Open Group, Len led the Worldwide Architecture Profession Office for HP Services at Hewlett-Packard. He majored in Computer Science at MIT, and has over 40 years of experience in the IT business as both an individual contributor and a manager, within both product engineering and services business units. Len has worked for Digital Equipment Corporation, Data General Corporation, Prime Computer, Compaq and Hewlett Packard.  He is the lead inventor on six software patents on the object oriented management of distributed systems.

2 Comments

Filed under Business Architecture, Enterprise Architecture

Different Words Mean Different Things, Part 1

By Leonard Fehskens, The Open Group

Over on the LinkedIn Enterprise Architecture Network discussion group there is a thread on the relationship between Enterprise Architecture (EA) and Business Architecture that as of late November 2012 had run to over 4100 comments.

Some of the sprawl of this thread is due to the usual lack of discipline in staying on topic.  Some of it is due to the rehashing of well-worn themes as newcomers arrive.  It seems clear to me though, that even when long time contributors try to move the subject forward, a lot of the back and forth that fails to converge is a consequence of the community’s lack of an appropriate and widely shared vocabulary.

In particular, there are four words that many in the Enterprise and Business Architecture communities seem to use interchangeably – enterprise, business, organization and corporation.

Before I tackle this subject, there is some context I should provide.

First, people who know me consider me to be obsessive about the precise use of language, and they’re right.  I think of Enterprise Architecture as more a craft than a science, and as such, the language we use to express it is ordinary language (as opposed to, for example, mathematics).  To me it follows that it is especially important that we use that language carefully.

Second, I’m coming at this from the perspective of creating a profession and its supporting ecosystem.  I believe a profession should be broadly applicable, with specializations within the profession addressing more narrowly focused concerns.

Finally, though much of the discussion about Enterprise Architecture is in English, I acknowledge that for a large fraction of the community English is a second (or third) language.  So, while this post is specifically about English usage, I suspect much of it applies as well to other languages, and I don’t want to imply that the conventions of English usage are the only ones worthy of consideration.

That’s enough by way of preamble.

The EA community may not have agreed upon definitions of many of the words it uses, but as these words are drawn from the vernacular, the rest of the world does.  This conventional usage makes clear distinctions between enterprise, business, organization and corporation.

While it is true that these words all have some sense in which they are roughly synonymous, they have primary definitions that distinguish them from one another.  I think we ought to observe these distinctions because they are useful, especially in that they allow us to sensibly relate the concepts they represent to one another, and they do not needlessly foreclose the broader application of these concepts.

First, I’m going to propose definitions for these words to be used in the context of Enterprise Architecture.  Then I’m going to look at what these definitions imply about the relationships between the things these words denote, and how the current usage obscures or denies these relationships.

It’s very possible, if not likely, that you will not agree with these definitions.  I’ll deal with that later.

Enterprise

The Oxford English Dictionary (Compact Edition, 1971) defines “enterprise” as:

Derived from the French entreprendre, “to take in hand, undertake”.

    1. A design of which the execution is attempted; a piece of work taken in hand, an undertaking; chiefly, and now exclusively, a bold, arduous, or momentous undertaking.
      • b. engagement in such undertaking
    2. Disposition or readiness to engage in undertakings of difficulty, risk, or danger; daring spirit.
    3. The action of taking in hand; management, superintendence. Obsolete.

So, enterprise means “undertaking” or “endeavor,” especially one that is relatively ambitious.  Implicit in this concept of enterprise is the intentional action of one of more people.  It is intentional in the sense that the action is intended to achieve some outcome.  The role of people is important; we do not generally consider machines, regardless of their purpose, to exhibit “enterprise” in this sense.  For me, the essential properties of an enterprise are people and their activity in pursuit of explicit intent.

This is a deliberately, very broadly inclusive concept of enterprise.  All of the following are, in my opinion, enterprises:

  • A child’s lemonade stand
  • A club
  • A professional society
  • A committee or working group
  • A town, state or country government
  • An international/multinational coalition
  • A military unit
  • A department or ministry of defense
  • A for-profit, non-profit or not-for-profit corporation
  • A partnership
  • A consortium
  • A church
  • A university or college
  • A hospital

Business

English speakers commonly use the word “business” to mean three things, and are usually able to infer the intended meaning from context.  These three common meanings of business are:

Business-as-commerce: The exchange of goods and services for some form of compensation for the costs and risks of doing so.

Business-as-commercial-entity: An entity whose primary activity is the conduct of some form of business-as-commerce.  In colloquial terms, the primary purpose of such an entity is to “make money”, and if it does not “make money” it will “go out of business.”

Business-as-primary-concern: The primary concern or activity of some entity.

These three different commonly understood meanings of business make it possible for someone to say something like:

“The business of my business is business.”

I.e., “The business-as-primary-concern of my business-as-commercial-entity is business-as-commerce.”

Organization

An “organization” is a structured (i.e., “organized”) group of people and resources, usually acting in concert to achieve some shared purpose.

Corporation

Finally, a “corporation” is an organization structured and operated in a particular way so as to satisfy certain legal constraints and thus benefit from the legal consequences of that conformance.  Strictly speaking, a corporation is a legal entity that has an organization associated with it.  In the case of a “shell” or “dummy” corporation, the associated organization’s people and resources may be minimal.

Observations

Based on these definitions, one can make some observations.

An organization is typically the means by which an enterprise is realized.  Small scale enterprises may be realized by a single individual, which is a trivial case of an organization.

Not all organizations are business-as-commercial-entities.  Organizations that are not businesses will almost certainly conduct some business-as-commerce as an adjunct activity in support of their primary intent.

Not all enterprises have as their intent some form of business-as-commerce. An organization that realizes such an enterprise will not be a business-as-commercial-entity.  While all business-as-commercial-entities realize an enterprise, not all enterprises are realized by business-as-commercial-entities.

Not all organizations are corporations.

Not all business-as-commercial-entities are corporations.

These relationships are depicted below.

 Len diagram

This is a three-part series that discusses how our vocabulary affects the way we conceptualize Enterprise Architecture, Business Architecture and their relationship.  Part 2 will examine the effect of our definition of enterprise on how we think about EA. 

 Len Fehskens is Vice President of Skills and Capabilities at The Open GroupHe is responsible for The Open Group’s activities relating to the professionalization of the discipline of enterprise architecture. Prior to joining The Open Group, Len led the Worldwide Architecture Profession Office for HP Services at Hewlett-Packard. He majored in Computer Science at MIT, and has over 40 years of experience in the IT business as both an individual contributor and a manager, within both product engineering and services business units. Len has worked for Digital Equipment Corporation, Data General Corporation, Prime Computer, Compaq and Hewlett Packard.  He is the lead inventor on six software patents on the object oriented management of distributed systems.

5 Comments

Filed under Business Architecture, Enterprise Architecture

Call for Submissions

By Patty Donovan, The Open Group

The Open Group Blog is celebrating its second birthday this month! Over the past few years, our blog posts have tended to cover Open Group activities – conferences, announcements, our lovely members, etc. While several members and Open Group staff serve as regular contributors, we’d like to take this opportunity to invite our community members to share their thoughts and expertise on topics related to The Open Group’s areas of expertise as guest contributors.

Here are a few examples of popular guest blog posts that we’ve received over the past year

Blog posts generally run between 500 and 800 words and address topics relevant to The Open Group workgroups, forums, consortiums and events. Some suggested topics are listed below.

  • ArchiMate®
  • Big Data
  • Business Architecture
  • Cloud Computing
  • Conference recaps
  • DirectNet
  • Enterprise Architecture
  • Enterprise Management
  • Future of Airborne Capability Environment (FACE™)
  • Governing Board Businesses
  • Governing Board Certified Architects
  • Governing Board Certified IT Specialists
  • Identity Management
  • IT Security
  • The Jericho Forum
  • The Open Group Trusted Technology Forum (OTTF)
  • Quantum Lifecycle Management
  • Real-Time Embedded Systems
  • Semantic Interoperability
  • Service-Oriented Architecture
  • TOGAF®

If you have any questions or would like to contribute, please contact opengroup (at) bateman-group.com.

Please note that all content submitted to The Open Group blog is subject to The Open Group approval process. The Open Group reserves the right to deny publication of any contributed works. Anything published shall be copyright of The Open Group.

Patricia Donovan is Vice President, Membership & Events, at The Open Group and a member of its executive management team. In this role she is involved in determining the company’s strategic direction and policy as well as the overall management of that business area. Patricia joined The Open Group in 1988 and has played a key role in the organization’s evolution, development and growth since then. She also oversees the company’s marketing, conferences and member meetings. She is based in the U.S.

1 Comment

Filed under Uncategorized

Barcelona Highlights

By Steve Philp, The Open Group

Within a 15 minute walk of Camp Nou (home of FC Barcelona), The Open Group Conference “kicked off” on Monday morning with some excellent plenary presentations from Scott Radedztsky of Deloitte followed by Peter Haviland and Mick Adams of Ernst & Young, and after the break from Helen Sun of Oracle and finally Ron Tolido and Manuel Sevilla from Capgemini. You can see most of these Big Data presentations for yourself on The Open Group’s Livestream page.

The “second half” of the day was split into tracks for Big Data, Enterprise Architecture (EA), TOGAF® and ArchiMate®. Henry Franken of BiZZdesign talked about EA in terms of TOGAF and ArchiMate (you can see this on our Livestream site, too) and the other ArchiMate presentations from Peter Filip of Tatra Bank, Gerben Wierda of APG Asset Management and Mieke Mahakena of Capgemini were also well received by an enthusiastic audience. Networking and drinks followed at the end of the track sessions, and the “crowd” went away happy after day one.

Tuesday started with a plenary presentation by Dr. Robert Winter from the University of St Gallen on EA and Transformation Management. See the following clip to learn more about his presentation and his research.


This was followed by tracks on distributed services architecture, security, TOGAF 9 case studies, information architecture, quantum lifecycle management (QLM) and a new track on Practice Driven Research on Enterprise Transformation (PRET) and Trends in EA Research (TEAR). The evening entertainment on day two consisted of dinner and a spectacular flamenco dancing show at the Palacio de Flamenco – where a good time was had by all.

After the show there was also time for a number of us to watch Barcelona v. Celtic in their European Champions League match at the Camp Nou. This is the view from my seat:

 

The game ended in a 2-1 victory for Barcelona, and following the game there was much debate and friendly banter in the bar between the conference delegates and the Celtic fans that were staying at our hotel.

The track theme continued on day three of the conference along with member meetings such as the next version of TOGAF Working Group, the TOGAF Standard and ArchiMate Language Harmonization Project, Certification Standing Committee, and TOGAF Value Realization Working Group, etc. Member meetings of the Architecture Forum and Security Forum were held on Thursday and brought the Barcelona event to its conclusion.

At the end of the day, if your “goal” is to listen to some great presentations, network with your peers, participate in meetings and influence the generation of new IT standards, then you should get a ticket for our next fixture in Newport Beach, Calif., USA on January 28-31, 2013. The theme, again, will be Big Data.

I look forward to seeing you there!

Steve Philp is the Marketing Director at The Open Group. Over the past 20 years, Steve has worked predominantly in sales, marketing and general management roles within the IT training industry. Based in Reading, UK, he joined the Open Group in 2008 to promote and develop the organization’s skills and experience-based IT certifications. More recently, he has become responsible for corporate marketing as well as certification.

Comments Off

Filed under Conference

SOA Provides Needed Support for Enterprise Architecture in Cloud, Mobile, Big Data, Says Open Group Panel

By Dana Gardner, BriefingsDirect

There’s been a resurgent role for service-oriented architecture (SOA) as a practical and relevant ingredient for effective design and use of Cloud, mobile, and big data technologies.

To find out why, The Open Group recently gathered an international panel of experts to explore the concept of “architecture is destiny,” especially when it comes to hybrid services delivery and management. The panel shows how SOA is proving instrumental in allowing the needed advancements over highly distributed services and data, when it comes to scale, heterogeneity support, and governance.

The panel consists of Chris Harding, Director of Interoperability at The Open Group, based in the UK; Nikhil Kumar, President of Applied Technology Solutions and Co-Chair of the SOA Reference Architecture Projects within The Open Group, and he’s based in Michigan, and Mats Gejnevall, Enterprise Architect at Capgemini and Co-Chair of The Open Group SOA Work Group, and he’s based in Sweden. The discussion is moderated by Dana Gardner, Principal Analyst at Interarbor Solutions.

The full podcast can be found here.

Here are some excerpts:

Gardner: Why this resurgence in the interest around SOA?

Harding: My role in The Open Group is to support the work of our members on SOA, Cloud computing, and other topics. We formed the SOA Work Group back in 2005, when SOA was a real emerging hot topic, and we set up a number of activities and projects. They’re all completed.

I was thinking that the SOA Work Group would wind down, move into maintenance mode, and meet once every few months or so, but we still get a fair attendance at our regular web meetings.

In fact, we’ve started two new projects and we’re about to start a third one. So, it’s very clear that there is still an interest, and indeed a renewed interest, in SOA from the IT community within The Open Group.

Larger trends

Gardner: Nikhil, do you believe that this has to do with some of the larger trends we’re seeing in the field, like Cloud Software as a Service (SaaS)? What’s driving this renewal?

Kumar: What I see driving it is three things. One is the advent of the Cloud and mobile, which requires a lot of cross-platform delivery of consistent services. The second is emerging technologies, mobile, big data, and the need to be able to look at data across multiple contexts.

The third thing that’s driving it is legacy modernization. A lot of organizations are now a lot more comfortable with SOA concepts. I see it in a number of our customers. I’ve just been running a large Enterprise Architecture initiative in a Fortune 500 customer.

At each stage, and at almost every point in that, they’re now comfortable. They feel that SOA can provide the ability to rationalize multiple platforms. They’re restructuring organizational structures, delivery organizations, as well as targeting their goals around a service-based platform capability.

So legacy modernization is a back-to-the-future kind of thing that has come back and is getting adoption. The way it’s being implemented is using RESTful services, as well as SOAP services, which is different from traditional SOA, say from the last version, which was mostly SOAP-driven.

Gardner: Mats, do you think that what’s happened is that the marketplace and the requirements have changed and that’s made SOA more relevant? Or has SOA changed to better fit the market? Or perhaps some combination?

Gejnevall: I think that the Cloud is really a service delivery platform. Companies discover that to be able to use the Cloud services, the SaaS things, they need to look at SOA as their internal development way of doing things as well. They understand they need to do the architecture internally, and if they’re going to use lots of external Cloud services, you might as well use SOA to do that.

Also, if you look at the Cloud suppliers, they also need to do their architecture in some way and SOA probably is a good vehicle for them. They can use that paradigm and also deliver what the customer wants in a well-designed SOA environment.

Gardner: Let’s drill down on the requirements around the Cloud and some of the key components of SOA. We’re certainly seeing, as you mentioned, the need for cross support for legacy, Cloud types of services, and using a variety of protocol, transports, and integration types. We already heard about REST for lightweight approaches and, of course, there will still be the need for object brokering and some of the more traditional enterprise integration approaches.

This really does sound like the job for an Enterprise Service Bus (ESB). So let’s go around the panel and look at this notion of an ESB. Some people, a few years back, didn’t think it was necessary or a requirement for SOA, but it certainly sounds like it’s the right type of functionality for the job.

Loosely coupled

Harding: I believe so, but maybe we ought to consider that in the Cloud context, you’re not just talking about within a single enterprise. You’re talking about a much more loosely coupled, distributed environment, and the ESB concept needs to take account of that in the Cloud context.

Gardner: Nikhil, any thoughts about how to manage this integration requirement around the modern SOA environment and whether ESBs are more or less relevant as a result?

Kumar: In the context of a Cloud we really see SOA and the concept of service contracts coming to the fore. In that scenario, ESBs play a role as a broker within the enterprise. When we talk about the interaction across Cloud-service providers and Cloud consumers, what we’re seeing is that the service provider has his own concept of an ESB within its own internal context.

If you want your Cloud services to be really reusable, the concept of the ESB then becomes more for the routing and the mediation of those services, once they’re provided to the consumer. There’s a kind of separation of concerns between the concept of a traditional ESB and a Cloud ESB, if you want to call it that.

The Cloud context involves more of the need to be able to support, enforce, and apply governance concepts and audit concepts, the capabilities to ensure that the interaction meets quality of service guarantees. That’s a little different from the concept that drove traditional ESBs.

That’s why you’re seeing API management platforms like Layer 7Mashery, or Apigee and other kind of product lines. They’re also coming into the picture, driven by the need to be able to support the way Cloud providers are provisioning their services. As Chris put it, you’re looking beyond the enterprise. Who owns it? That’s where the role of the ESB is different from the traditional concept.

Most Cloud platforms have cost factors associated with locality. If you have truly global enterprises and services, you need to factor in the ability to deal with safe harbor issues and you need to factor in variations and law in terms of security governance.

The platforms that are evolving are starting to provide this out of the box. The service consumer or a service provider needs to be able to support those. That’s going to become the role of their ESB in the future, to be able to consume a service, to be able to assert this quality-of-service guarantee, and manage constraints or data-in-flight and data-at-rest.

Gardner: Mats, are there other aspects of the concept of ESB that are now relevant to the Cloud?

Entire stack

Gejnevall: One of the reasons SOA didn’t really take off in many organizations three, four, or five years ago was the need to buy the entire stack of SOA products that all the consultancies were asking companies to buy, wanting them to buy an ESB, governance tools, business process management tools, and a lot of sort of quite large investments to just get your foot into the door of doing SOA.

These days you can buy that kind of stuff. You can buy the entire stack in the Cloud and start playing with it. I did some searches on it today and I found a company that you can play with the entire stack, including business tools and everything like that, for zero dollars. Then you can grow and use more and more of it in your business, but you can start to see if this is something for you.

In the past, the suppliers or the consultants told you that you could do it. You couldn’t really try it out yourself. You needed both the software and the hardware in place. The money to get started is much lower today. That’s another reason people might be thinking about it these days.

Gardner: It sounds as if there’s a new type of on-ramp to SOA values, and the componentry that supports SOA is now being delivered as a service. On top of that, you’re also able to consume it in a pay-as-you-go manner.

Harding: That’s a very good point, but there are two contradictory trends we are seeing here. One is the kind of trend that Mats is describing, where the technology you need to handle a complex stack is becoming readily available in the Cloud.

And the other is the trend that Nikhil mentioned: to go for a simpler style, which a lot of people term REST, for accessing services. It will be interesting to see how those two tendencies play out against each other.

Kumar: I’d like to make a comment on that. The approach for the on-ramp is really one of the key differentiators of the Cloud, because you have the agility and the lack of capital investment (CAPEX) required to test things out.

But as we are evolving with Cloud platforms, I’m also seeing with a lot of Platform-as-a-Service (PaaS) vendor scenarios that they’re trying the ESB in the stack itself. They’re providing it in their Cloud fabric. A couple of large players have already done that.

For example, Azure provides that in the forward-looking vision. I am sure IBM and Oracle have already started down that path. A lot of the players are going to provide it as a core capability.

Pre-integrated environment

Gejnevall: Another interesting thing is that they could get a whole environment that’s pre-integrated. Usually, when you buy these things from a vendor, a lot of times they don’t fit together that well. Now, there’s an effort to make them work together.

But some people put these open-source tools together. Some people have done that and put them out on the Cloud, which gives them a pretty cheap platform for themselves. Then, they can sell it at a reasonable price, because of the integration of all these things.

Gardner: The Cloud model may be evolving toward an all-inclusive offering. But SOA, by its definition, advances interoperability, to plug and play across existing, current, and future sets of service possibilities. Are we talking about SOA being an important element of keeping Clouds dynamic and flexible — even open?

Kumar: We can think about the OSI 7 Layer Model. We’re evolving in terms of complexity, right? So from an interoperability perspective, we may talk SOAP or REST, for example, but the interaction with AWS, SalesforceSmartCloud, or Azure would involve using APIs that each of these platforms provide for interaction.

Lock-in

So you could have an AMI, which is an image on the Amazon Web Services environment, for example, and that could support a lab stack or an open source stack. How you interact with it, how you monitor it, how you cluster it, all of those aspects now start factoring in specific APIs, and so that’s the lock-in.

From an architect’s perspective, I look at it as we need to support proper separation of concerns, and that’s part of [The Open Group] SOA Reference Architecture. That’s what we tried to do, to be able to support implementation architectures that support that separation of concerns.

There’s another factor that we need to understand from the context of the Cloud, especially for mid-to-large sized organizations, and that is that the Cloud service providers, especially the large ones — Amazon, Microsoft, IBM — encapsulate infrastructure.

If you were to go to Amazon, Microsoft, or IBM and use their IaaS networking capabilities, you’d have one of the largest WAN networks in the world, and you wouldn’t have to pay a dime to establish that infrastructure. Not in terms of the cost of the infrastructure, not in terms of the capabilities required, nothing. So that’s an advantage that the Cloud is bringing, which I think is going to be very compelling.

The other thing is that, from an SOA context, you’re now able to look at it and say, “Well, I’m dealing with the Cloud, and what all these providers are doing is make it seamless, whether you’re dealing with the Cloud or on-premise.” That’s an important concept.

Now, each of these providers and different aspects of their stacks are at significantly different levels of maturity. Many of these providers may find that their stacks do not interoperate with themselves either, within their own stacks, just because they’re using different run times, different implementations, etc. That’s another factor to take in.

From an SOA perspective, the Cloud has become very compelling, because I’m dealing, let’s say, with a Salesforce.com and I want to use that same service within the enterprise, let’s say, an insurance capability for Microsoft Dynamics or for SugarCRM. If that capability is exposed to one source of truth in the enterprise, you’ve now reduced the complexity and have the ability to adopt different Cloud platforms.

What we are going to start seeing is that the Cloud is going to shift from being just one à-la-carte solution for everybody. It’s going to become something similar to what we used to deal with in the enterprise context. You had multiple applications, which you service-enabled to reduce complexity and provide one service-based capability, instead of an application-centered approach.

You’re now going to move the context to the Cloud, to your multiple Cloud solutions, and maybe many implementations in a nontrivial environment for the same business capability, but they are now exposed to services in the enterprise SOA. You could have Salesforce. You could have Amazon. You could have an IBM implementation. And you could pick and choose the source of truth and share it.

So a lot of the core SOA concepts will still apply and are still applying.

Another on-ramp

Gardner: Perhaps yet another on-ramp to the use of SOA is the app store, which allows for discovery, socialization of services, but at the same time provides overnance and control?

Kumar: We’re seeing that with a lot of our customers, typically the vendors who support PaaS solution associate app store models along with their platform as a mechanism to gain market share.

The issue that you run into with that is, it’s okay if it’s on your cellphone or on your iPad, your tablet PC, or whatever, but once you start having managed apps, for example Salesforce, or if you have applications which are being deployed on an Azure or on a SmartCloud context, you have high risk scenario. You don’t know how well architected that application is. It’s just like going and buying an enterprise application.

When you deploy it in the Cloud, you really need to understand the Cloud PaaS platform for that particular platform to understand the implications in terms of dependencies and cross-dependencies across apps that you have installed. They have real practical implications in terms of maintainability and performance. We’ve seen that with at least two platforms in the last six months.

Governance becomes extremely important. Because of the low CAPEX implications to the business, the business is very comfortable with going and buying these applications and saying, “We can install X, Y, or Z and it will cost us two months and a few million dollars and we are all set.” Or maybe it’s a few hundred thousand dollars.

They don’t realize the implications in terms of interoperability, performance, and standard architectural quality attributes that can occur. There is a governance aspect from the context of the Cloud provisioning of these applications.

There is another aspect to it, which is governance in terms of the run-time, more classic SOA governance, to measure, assert, and to view the cost of these applications in terms of performance to your infrastructural resources, to your security constraints. Also, are there scenarios where the application itself has a dependency on a daisy chain, multiple external applications, to trace the data?

In terms of the context of app stores, they’re almost like SaaS with a particular platform in mind. They provide the buyer with certain commitments from the platform manager or the platform provider, such as security. When you buy an app from Apple, there is at least a reputational expectation of security from the vendor.

What you do not always know is if that security is really being provided. There’s a risk there for organizations who are exposing mission-critical data to that.

The second thing is there is still very much a place for the classic SOA registries and repositories in the Cloud. Only the place is for a different purpose. Those registries and repositories are used either by service providers or by consumers to maintain the list of services they’re using internally.

Different paradigms

There are two different paradigms. The app store is a place where I can go and I know that the gas I am going to get is 85 percent ethanol, versus I also have to maintain some basic set of goods at home to make that I have my dinner on time. These are different kind of roles and different kind of purposes they’re serving.

Above all, I think the thing that’s going to become more and more important in the context of the Cloud is that the functionality will be provided by the Cloud platform or the app you buy, but the governance will be a major IT responsibility, right from the time of picking the app, to the time of delivering it, to the time of monitoring it.

Gardner: How is The Open Group allowing architects to better exercise SOA principles, as they’re grappling with some of these issues around governance, hybrid services delivery and management, and the use and demand in their organizations to start consuming more Cloud services?

Harding: The architect’s primary concern, of course, has to be to meet the needs of the client and to do so in a way that is most effective and that is cost-effective. Cloud gives the architect a usability to go out and get different components much more easily than hitherto.

There is a problem, of course, with integrating them and putting them together. SOA can provide part of the solution to that problem, in that it gives a principle of loosely coupled services. If you didn’t have that when you were trying to integrate different functionality from different places, you would be in a real mess.

What The Open Group contributes is a set of artifacts that enable the architect to think through how to meet the client’s needs in the best way when working with SOA and Cloud.

For example, the SOA Reference Architecture helps the architect understand what components might be brought into the solution. We have the SOA TOGAF Practical Guide, which helps the architect understand how to use TOGAF® in the SOA context.

We’re working further on artifacts in the Cloud space, the Cloud Computing Reference Architecture, a notational language for enabling people to describe Cloud ecosystems on recommendations for Cloud interoperability and portability. We’re also working on recommendations for Cloud governance to complement the recommendations for SOA governance, the SOA Governance Framework Standards that we have already produced, and a number of other artifacts.

The Open Group’s real role is to support the architect and help the architect to better meet the needs of the architect client.

From the very early days, SOA was seen as bringing a closer connection between the business and technology. A lot of those promises that were made about SOA seven or eight years ago are only now becoming possible to fulfill, and that business front is what that project is looking at.

We’re also producing an update to the SOA Reference Architectures. We have input the SOA Reference Architecture for consideration by the ISO Group that is looking at an International Standard Reference Architecture for SOA and also to the IEEE Group that is looking at an IEEE Standard Reference Architecture.

We hope that both of those groups will want to work along the principles of our SOA Reference Architecture and we intend to produce a new version that incorporates the kind of ideas that they want to bring into the picture.

We’re also thinking of setting up an SOA project to look specifically at assistance to architects building SOA into enterprise solutions.

So those are three new initiatives that should result in new Open Group standards and guides to complement, as I have described already, the SOA Reference Architecture, the SOA Governance Framework, the Practical Guides to using TOGAF for SOA.

We also have the Service Integration Maturity Model that we need to assess the SOA maturity. We have a standard on service orientation applied to Cloud infrastructure, and we have a formal SOA Ontology.

Those are the things The Open Group has in place at present to assist the architect, and we are and will be working on three new things: version 2 of the Reference Architecture for SOA, SOA for business technology, and I believe shortly we’ll start on assistance to architects in developing SOA solutions.

Dana Gardner is the Principal Analyst at Interarbor Solutions, which identifies and interprets the trends in Services-Oriented Architecture (SOA) and enterprise software infrastructure markets. Interarbor Solutions creates in-depth Web content and distributes it via BriefingsDirect™ blogs, podcasts and video-podcasts to support conversational education about SOA, software infrastructure, Enterprise 2.0, and application development and deployment strategies.

Comments Off

Filed under Cloud, Cloud/SOA, Service Oriented Architecture

Alex Osterwalder’s Business Model Canvas

By The Open Group Conference Team

At The Open Group Conference in Cannes, Alex Osterwalder, entrepreneur, “Business Model Generation” author and creator of the Business Model Canvas, discussed how enterprise architects can contribute to business models. He suggested that there needs to be a bridge between Enterprise Architecture and the highest strategic level of business, bringing strategic and implementation concepts together.  Osterwalder also encouraged organizations to have a shared discussion in a shared language with all stakeholders – a concept that enterprise architects are very familiar with.

To hear more from Alex Osterwalder on how enterprise architects can become more involved in the business model development process, please watch this video:

 

Later this month, The Open Group is hosting its Barcelona conference from October 22-25, where industry thought leaders, like Osterwalder, will be discussing emerging IT trends, specifically the concept of Big Data – the next frontier in the enterprise.

1 Comment

Filed under Business Architecture, Conference

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

The Open Group Barcelona Conference – Early Bird Registration ends September 21

By The Open Group Conference Team

Early Bird registration for The Open Group Conference in Barcelona ends September 21. Register now and save!

The conference runs October 22-24, 2012. On Monday, October 22, the plenary theme is “Big Data – The Next Frontier in the Enterprise,” and speakers will address the challenges and solutions facing Enterprise Architecture within the context of the growth of Big Data. Topics to be explored include:

  • How does an enterprise adopt the means to contend with Big Data within its information architecture?
  • How does Big Data enable your business architecture?
  • What are the issues concerned with real-time analysis of the data resources on the cloud?
  • What are the information security challenges in the world of outsourced and massively streamed data analytics?
  • What is the architectural view of security for cloud computing? How can you take a risk-based approach to cloud security?

Plenary speakers include:

  • Peter Haviland, head of Business Architecture, Ernst & Young
  • Ron Tolido, CTO of Application Services in Europe, Capgemini; and Manuel Sevilla, chief technical officer, Global Business Information Management, Capgemini
  • Scott Radeztsky, chief technical officer, Deloitte Analytics Innovation Centers
  • Helen Sun, director of Enterprise Architecture, Oracle

On Tuesday, October 23, Dr. Robert Winter, Institute of Information Management, University of St. Gallen, Switzerland, will kick off the day with a keynote on EA Management and Transformation Management.

Tracks include:

  • Practice-driven Research on Enterprise Transformation (PRET)
  • Trends in Enterprise Architecture Research (TEAR)
  • TOGAF® and ArchiMate® Case Studies
  • Information Architecture
  • Distributed Services Architecture
  • Holistic Enterprise Architecture Workshop
  • Business Innovation & Technical Disruption
  • Security Architecture
  • Big Data
  • Cloud Computing for Business
  • Cloud Security and Cloud Architecture
  • Agile Enterprise Architecture
  • Enterprise Architecture and Business Value
  • Setting Up A Successful Enterprise Architecture Practice

For more information or to register: http://www.opengroup.org/barcelona2012/registration

Comments Off

Filed under Conference

Video Highlights Day 2 of Washington, D.C.

By The Open Group Conference Team

How can you use the tools of Enterprise Architecture and open standards to improve the capability of your company doing business? The Day 2 speakers of The Open Group Conference in Washington, D.C. addressed this question, focusing on Enterprise Transformation. Sessions included:

  • “Case Study: University Health Network (Toronto),” by Jason Uppal, chief enterprise architect at QR Systems, Inc. and winner of the 2012 Edison Award for Innovation
  • “Future Airborne Capability Environment (FACE™): Transforming the DoD Avionics Software Industry Through the Use of Open Standards,” by Judy Cerenzia, FACE™ program director at The Open Group, Kirk Avery, chief software architect at Lockheed Martin and Philip Minor, director at System of Systems of Engineering Directorate at the Office of Chief Systems Engineer, ASA(ALT)
  • “Using the TOGAF® Architecture Content Framework with the ArchiMate® Modeling Language,” by Henry Franken, CEO of BIZZdesign, and Iver Band, enterprise architect at Standard Insurance

David Lounsbury, CTO of The Open Group summarizes some of the day’s sessions:

Comments Off

Filed under Uncategorized, Enterprise Architecture, Cybersecurity, TOGAF®, Certifications, ArchiMate®, Information security, FACE™, Business Architecture, Enterprise Transformation, Conference

Monet revisited (or: non-traditional approaches to developing TOGAF® Next)

By Stuart Boardman, Getronics

Right now work is starting on the next major release of TOGAF®, which for now is known as TOGAF® Next. That makes it a very good time to look at what else is going on in the world and what kind of contribution that might make.

A lot of the best ideas come from unexpected directions. Enterprise architects (fortunately) often have passions that don’t have much directly to do with that discipline. Let’s be honest, the best ones almost always do. Peter Bakker recently drew our attention to a current debate in the world of photography and photo journalism. People are using apps like Hipstamatic to make deliberately grungy images – to make the results less “realistic” and more “impressionistic” (same thing Claude Monet and his pals came up with in the late 19th century except they didn’t have apps back then). Apart from the intrinsic interest of the topic, Peter suggested this might be applicable in EA. That made me think. We’ve invested vast amounts of time and effort (and therefore money) in being able to specify things in enormous detail according to increasingly tightly defined models. In fact, people used to complain that those tight models were what TOGAF® lacked. Hmmm. Sometimes the result is not seeing the wood for the trees. Or assuming that detail equals fact. Or getting realism muddled up with reality. Or information with knowledge (never mind wisdom). The Impressionists wanted people to be able to get a feeling of what it was like to be there — not precisely what it looked like at a specific moment in time. So while I’m sure they weren’t thinking about quantum mechanics (that would have been quite an achievement!), they were certainly leaving things open for probabilistic interpretations. Could we do the same in EA – without just producing vagueness? Why not – at least down to a certain level? If you use the Business Model Canvas, for example, you can build up a very meaningful picture of an enterprise’s business model without vast amounts of detail. It provides a lot of knowledge and even some wisdom on the basis of an optimal amount of information. And that has the great benefit of allowing you to fill in the detail where it’s actually going to be useful to you. So why wouldn’t we do something similar in general in EA?

Ross Button is developing an idea he calls Scatter Architecture. You could visualize it as a lot of puzzle pieces that you scatter on a board and see what kind of a picture you can make out of them. They might turn out to fit together in more than one way. That’s actually a good thing, as it probably makes you more adaptable and less exposed to change. Some of the pieces will duplicate each other wholly or partly. Viewed from a TOGAF® perspective we can say that these duplicates occur both on the Enterprise Continuum and on the Solution Continuum. Duplicates are allowed in this architecture. I don’t suppose you’d find them in the Enterprise Strategy or in the Architecture Strategy but you might well find partial duplicates among your propositions, activities, resources and partners – particularly the latter. After all, you probably don’t really want to be dependent on one supplier but that doesn’t mean they’re all exactly alike. So your architecture strategy might even codify that, which means your architecture models will need to take account of it. On the solution side of things it’s just as likely. Ross has explicitly pointed to Cloud as an example of this. Just as in the “real” world, if you can avoid being locked into just one supplier (without the cost implications being too high), you have much more room to manoeuver. The Amazon crash a couple of months ago provided some good positive and negative examples. Moreover, just as in the “real” world, these partners might become part of your value creation process as opposed to just cost elements. So this introduces my second theme, multiplicity.

Louisa Leontiades has just launched a social media integrated business. It’s a great example of how enterprises are changing and why we need to understand them in non-traditional ways. What can we say about her business? Well, it’s an Internet company but it’s not selling technology. It sells real people skills but everything lives in the blogosphere. You can buy her stuff via the site but it’s not an eShop. It’s Louisa’s company but in some ways it’s a virtual enterprise. What does that mean? Well, there will be multiple contributors generating and selling content and the quality and commercial success of the content will shape how the company develops. Or to put it another way, the contributors are not merely suppliers but actually investors, who benefit from the success of the company. Oh and it has its own website but the marketing happens via separate blog sites, via Twitter, Facebook, Google+, LinkedIn – you name it. It’s easy to see then how capturing the architecture of such an enterprise is about capturing the essence and not getting distracted by detail that can change at any moment – exactly due to the multiplicity of contributors and propositions. It’s a daring concept – jumping into the unknown – and of course we won’t see this model in the large enterprise world for quite some time but in the non-profit world or perhaps even in education one could imagine a more rapid adoption. In fact you might reasonably expect to see it adopted in education. It was after all educational and research organizations that gave us the Web in the first place. And back then the web was all about collaboration and sharing – co-creation.

Tom Graves has been looking at extending the Business Model Canvas into Enterprise Architecture as a whole. One part of this is extending it upwards (or outwards – depends how you look at it) to reflect the extended enterprise context in which most organizations “live” today. This involves taking concepts which we already apply to the single enterprise and applying them to a world we don’t control, where multiplicity is the rule and in which our objective is to be an equal partner. This gives rise to relationships, which are both complex and shifting. I would argue that one consequence is that we need to put the emphasis on capturing the entirety of the situation, so we can understand its dynamics and reach (breadth), and we need to avoid the distraction of those details, which we know can and will change without our being consulted (anyone see a similarity to Cloud here?). Another part of what Tom is doing is a mapping with Archimate. I don’t know whether Tom sees it exactly the way I do, but I think one of the advantages is that it combines the impressionist approach with a standardized modeling technique and allows us to provide detail where it’s meaningful and useful. And what it also does is provide a semi-formalized way of using techniques coming from a different discipline within (or along with) familiar EA frameworks. Well, I say “does” but I should say “will do”. It’s work in progress, just like Scatter. Just like TOGAF® Next. You can contribute to these things, influence them or adapt them to your own purposes. You can read and leave them aside but at least you’ll have thought about it. And that in and of itself will enrich your practice.

Stuart Boardman is a Senior Business Consultant with Getronics Consulting where he co-leads the Enterprise Architecture practice as well as the Cloud Computing solutions group. He is co-lead of The Open Group Cloud Computing Work Group’s Security for the Cloud and SOA project and a founding member of both The Open Group Cloud Computing Work Group and The Open Group SOA Work Group. Stuart is the author of publications by the Information Security Platform (PvIB) in The Netherlands and of his previous employer, CGI. He is a frequent speaker at conferences on the topics of Cloud, SOA, and Identity. 

1 Comment

Filed under Enterprise Architecture, TOGAF®

Google+, spiral galaxies and Louisa’s bright idea

By Stuart Boardman, Getronics

Even a social media lightweight like me could hardly avoid getting caught up in the Google+ hype. It got me thinking about the rate and unpredictability of change in the web world, and the effect on large enterprises of phenomena originating in the consumer and small business market.

The concept of the enterprise is experiencing a change – maybe a radical one. The role of technology is also changing (not for the first time).  New business models are developing which, whilst not technological in nature, would never have been thought of without the technology developments of the last few years. Other business models, around for a bit longer and not technological in nature are pushing technology in a different direction. Business models themselves are subject to increasingly frequent and not always predictable change. What does this mean for the practice of enterprise architecture?

Back to Google+. A few years ago, when Web 2.0 was the buzzword and everyone conveniently forgot that the web actually started out as a vehicle for user-generated content and collaboration (sorry, had to get that off my chest), there was quite a battery of social media providers all with their own specializations: Facebook, MySpace, LinkedIn, Plaxo, Flickr and a whole bunch of sites for gamers and metal fans, etc. In Holland, where I live, we had our own, very successful variant on Facebook. Had. In the period since then there’s been increasing consolidation with Facebook developing an astonishing hegemony. I’ll admit that I assumed that’s how it would stay until a new Zuckerberg came up with a totally new game changer. But now here comes Google with a new spin on a familiar story and they look set to chew a big chunk out of the market. Perhaps even the enterprise market.

What’s this have to do with enterprises? Well, the fact is that everyone in the enterprise is out there exchanging ideas via Twitter and LinkedIn and Facebook and Google+ (and whatever specialized sites they might use) and they’re even using those media to tell the rest of the enterprise that they published something internally – because otherwise no one will notice. And then there’s co-creation, which is becoming increasingly common – even in large enterprises. So like it or not, the enterprise is being irreversibly extended out into the blogosphere. And that means that the enterprise is far more exposed to the trends and rapid shifts in the world outside its own boundaries than it has ever been before.

In the meantime, a lot of other stuff has been changing for the enterprise. Extended Enterprise, the idea that an enterprise’s business processes (some of them) are performed by third parties, who themselves are part of a broad value network, is pretty much established fact for many large and medium-sized organizations. And there are unexpected new business models emerging. Think about app stores. I can’t see inside Steve Jobs’ head but I suspect the app store was developed to support the iPhone – not the other way around. Just like iTunes was developed to support the iPod. But now everyone has app stores (even if Apple doesn’t want them to use the name). The end result of all this has been to create a whole new market, where new entrepreneurs can develop low-cost software and sell it in bulk across multiple platforms and where those platforms could hardly exist without the app developers. I’m even using an iPhone app (also available on Android) to drive my domestic hi-fi system (from a very respectable English high end designer – not some uber-nerd). The app strengthens the business case for the equipment and makes money for the developer. The app didn’t come with the equipment; I bought it at the app store. App stores themselves are new value propositions for their owners (Apple, etc). In some ways we could regard this as a commercial instantiation of the old Virtual Enterprise idea – an “enterprise” consisting of a loosely coupled, shifting alliance of unrelated legal entities. I like this recent quote from Verna Allee (@vernaallee): “Business models often assume the world revolves around our organization when we really revolve in spiral galaxy ecosystems”. Louisa Leontiades (@MoneyDecisions) is launching a web based, social media driven consultancy, which provides a sort of app store where independent experts can sell tools and frameworks (and yes, get consultancy deals too). Brilliant. And of course all this represents a very scattered field of players, business models and solutions.

How are these developments reflected in Enterprise Architecture? In particular what is the effect on architecture vision and the idea of a target state?  I came across another interesting discussion recently. Robert Phipps (@robert_phipps) suggested in a discussion with Tom Graves (@tetradian) that an enterprise consists of many vectors, each with its own direction and velocity and each potentially colliding with and therefore affecting the direction and velocity of the others. Sounds pretty abstract but if you accept the metaphor you can see that the target state is going to be different depending on how the various collisions work out. In a “traditional” enterprise, the power relationships between the various vectors is pretty stable and the influence of external factors limited to macro-economic effects. The metaphor is still valid but the scale of the problem much smaller (less entropy). If what I wrote above is correct, there aren’t too many “traditional” enterprises these days.  Tom took the metaphor a bit further and made reference to Quantum theory. That’s also interesting, because it focuses on a probabilistic situation. Architecting for uncertainty. Welcome to the real world. That doesn’t mean there is no value in a target. You have to have some idea what you want to achieve based on what you know now. It just doesn’t need to be too prescriptive. Or put another way, it needs not to be too sensitive to unpredictability. Everything (not just the technology) is likely to have changed before you get there. It certainly increases the relative importance of the first steps on the road to that target. The less particle/vector collisions take place within one step, the more chance of achieving something useful. After each step we re-evaluate both target and roadmap. Iterate. Agile EA. And guess what? This is what we’re supposed to do anyway – design for change, constant delivery of value. No “wait a year and we’ll have something for you”. So if we’ve not been doing that, we’ve not been doing what the enterprise needed from us. All that’s changed is that we will become increasingly irrelevant, if we don’t do it.

Stuart Boardman is a Senior Business Consultant with Getronics Consulting where he co-leads the Enterprise Architecture practice as well as the Cloud Computing solutions group. He is co-lead of The Open Group Cloud Computing Work Group’s Security for the Cloud and SOA project and a founding member of both The Open Group Cloud Computing Work Group and The Open Group SOA Work Group. Stuart is the author of publications by the Information Security Platform (PvIB) in The Netherlands and of his previous employer, CGI. He is a frequent speaker at conferences on the topics of Cloud, SOA, and Identity.

Comments Off

Filed under Enterprise Architecture

Enterprise IT’s Inflection Point!

By Balasubramanian Somasundram, Honeywell Technology Solutions Ltd.

Of late, the online media is flooded with plenty of articles/opinions on the future of Enterprise IT and CIO roles in next decades! It’s interesting to read many different perspectives on the possibilities.

But the biggest question is – Why now? Why do we see such futuristic, inspirational, transformational viewpoints doing the rounds these days? I strongly believe that Enterprise IT is at its inflection point due to two main mega trends happening in the industry.

One is the introduction of Cloud Computing, and another is IT getting pervasive and embedded in almost all products and services that touch the end consumer. The irony is, these trends pose the biggest threats and biggest opportunities! I am going to talk about the opportunities here.

As mentioned in the CIO.com article, “The Cloud CIO: A Tale of Two IT Futures,” one of the potential approaches for leveraging these trends could be to push Enterprise IT’s non-core portfolio to Cloud Computing and divest those saved efforts in partnering with business to build new products and services. Here is an interesting perspective published in InformationWeek where Chris Murphy takes a stand that IT must create products, not just cut costs.

I also believe the fundamental capability that would enable the Enterprise IT to accomplish this transition is IT’s Enterprise Architecture competencies. Enterprise IT organizations that have their strengths in architecture competencies — such as Technology Architecture, Business Architecture, Solution Architecture and Infrastructure Architecture — are bound to succeed in the mega trends of Cloud Computing and business partnering!

Adoption of emerging technologies and combining them with suitable business scenarios to deliver a compelling business solution calls for a strong Solution Architecture practice. The Solution Architecture is the System/Technical Architecture that realizes the Business Architecture scenarios.  Similarly, identification of non-core areas in the business/IT portfolio and transitioning to Cloud Computing requires a systemic view of the Enterprise and it should address the critical concerns such as data governance, security and infrastructure architecture.

In addition, IT’s traditional strengths such as project management, cost efficiency, security, licensing and software maintenance would be a big boon for software-intensive product businesses. These competencies in combination with Enterprise Architecture would be the stepping stone for the next biggest leap of Enterprise IT!

Balasubramanian Somasundaram is an Enterprise Architect with Honeywell Technology Solutions Ltd, Bangalore, a division of Honeywell Inc, USA. Bala has been with Honeywell Technology Solutions for the past five years and contributed in several technology roles. His current responsibilities include Architecture/Technology Planning and Governance, Solution Architecture Definition for business-critical programs, and Technical oversight/Review for programs delivered from Honeywell IT India center. With more than 12 years of experience in the IT services industry, Bala has worked with variety of technologies with a focus on IT architecture practice.  His current interests include Enterprise Architecture, Cloud Computing and Mobile Applications. He periodically writes about emerging technology trends that impact the Enterprise IT space on his blog. Bala holds a Master of Science in Computer Science from MKU University, India.

2 Comments

Filed under Cloud/SOA, Enterprise Architecture

Looking back at Day Three in Pune: The Open Group India Conference

By Raghuraman Krishnamurthy, Cognizant Technology Solutions

The Open Group India Conference in Pune on 11 March, 2011 was very well attended. The delegates actively participated in the Conference, ensuring a very lively day. In the morning, Mick Adams and Chris Forde spoke about ‘Architecture Trends Globally’, where they made interesting suggestions for using EA to articulate benefits to customers, employees and shareholders. They also said that EA efforts ideally should find a mention in the enterprise’s annual report, and that can be regarded as the touchstone for EA gaining its due recognition.

In the afternoon presentation on ‘Private Sector Multinational Deployment of TOGAF®, Mick Adams engaged the delegates with discussions around the relevance of certification in India. Several interesting points were debated:

  • How to ensure the certification process has the flavor of both theory and practical application
  • How certification helps in screening

The overall opinion was towards certification as a distinguishing credential. In another interesting discussion about how India can contribute to The Open Group, some interesting points were made:

  • How working groups have unearthly conference hours in Asia, naturally curtailing participation from India
  • How India, by working with enterprises across the globe, can provide the vantage view point to The Open Group

During my presentation on ‘Reorienting EA’, the delegates enthusiastically shared their experience of the flat world trends and their challenges in EA work. The day concluded with a panel discussion (on the EA track) on ‘Architecture Value – What Does This Mean for the Indian Marketplace?’ Thanks a lot to Capgemini and The Open Group for bringing this conference to India. I am sure it benefited all those who participated.

Raghuraman Krishnamurthy works as a Principal Architect at Cognizant Technology Solutions and is based in India. He can be reached at Raghuraman.krishnamurthy2@cognizant.com.

Comments Off

Filed under Enterprise Architecture

Enterprise Architecture’s Quest for its Identity

By Len Fehskens, The Open Group

It is my impression, from what I read and hear in many enterprise and business architecture blogs and forums, that the enterprise architecture community comprises multiple factions, and which faction you are part of depends on how you answer two questions. These are fundamental questions that I suspect many in the EA community (present company excepted, of course) have not asked themselves explicitly, or, if they have, considered why they would answer them one way or the other. I believe the answers to these questions color the way we talk and think about enterprise architecture, and until the EA community as a whole comes to a consensus regarding their answers, we risk talking past one another, using the same words but meaning significantly different things.

The two questions are:

  • Is enterprise architecture primarily about IT or is it about the entire enterprise?
  • Is enterprise architecture a “hard” discipline or a “soft” discipline?

My answers:

Enterprise architecture ought to be about the entire enterprise, because that’s what the name implies. If it’s really about IT, it ought to be called enterprise IT architecture. Whether or not you believe it’s possible or desirable to apply architectural thinking to the entire enterprise doesn’t change the fact that we ought to name things honestly. And when we name architectures, it seems reasonable to me to expect that if an architecture is implemented primarily in the <x> domain, it ought to be called an <x> architecture. Adding two more syllables (IT) to the seven (en-ter-prise ar-chi-tec-ture), or inserting two characters (IT) in the acronym (EA), isn’t an unbearable burden. Say it – “enterprise IT architecture.” Spell it – “EITA.”

Rarely has the cost of honesty been so modest. If you mean the architecture of an enterprise’s IT assets and capabilities, say EITA. Don’t say EA unless you really mean the architecture of the entire enterprise, not just its IT assets. Even if you consider the needs of the enterprise, or the structure of the enterprise’s processes, if the implementation of the architecture you’re developing will be mostly in the IT domain, it’s EITA, not EA. Even if you believe that architectural thinking can be meaningfully applied only to the IT function of an enterprise, it’s still EITA, not EA.

My answer to the second question is that I believe enterprise architecture, as scoped above, is a “soft” discipline. I think talking about “manufacturing” or “engineering” enterprises is just silly; it’s another example of the kind of aggrandizement that misnaming enterprise IT architecture represents.

Even calling an enterprise a “system” is risky. We use the word system in two senses. One is a very broadly inclusive idea, often expressed as “everything is a system,” in that many things can be viewed as assemblies or aggregates of smaller components. This concept of system is useful because it encourages us to take a holistic, rather than reductionist, perspective, acknowledging that the relationships between the pieces are as important as the individual pieces themselves. The other sense of “system” is the one engineers use – a system is an artifact that has been methodically designed and built from interconnected components. Calling something a system in the first sense doesn’t make it a system in the second sense; it doesn’t make its behavior and performance analytically tractable or deterministic.

It is simply not possible to specify an enterprise as completely, and to the same level of detail, as it is to specify a building or a locomotive or an airplane. And, for the purpose of enterprise architecture, i.e., to ensure that an enterprise’s assets and capabilities are aligned with its vision, mission and strategy, it isn’t necessary to do so, even if we could.

It may be possible to do so for EITA, and maybe that’s where the idea that the same can be said of the enterprise as a whole comes from.

If the enterprise as a whole is a system, it’s a people-intensive system, and as such one might as well talk about manufacturing or engineering people.

After all, why do we call them “enterprises”? Consider the first definition of the noun “enterprise” in the Oxford English Dictionary: “A design of which the execution is attempted; a piece of work taken in hand, an undertaking; chiefly, and now exclusively, a bold, arduous or momentous undertaking.” Clearly implicit in this definition is that this is something undertaken by people.  There’s a nod to this reality when we refer to an enterprise as a “sociotechnical system”, but the “socio” too often gets short shrift while the “technical” gets the bulk of the attention.

Yes, people play a role in other “systems” – they live and work in buildings, they drive locomotives and pilot airplanes. But people don’t just interact with an enterprise; in a fundamental sense, they are the enterprise. And unlike buildings and locomotives and airplanes, enterprises are continually adapting themselves, in the homeostatic sense of maintaining their integrity and identity in the face of internal and external change, and in the sense of deliberately repurposing themselves in response to such change.

How would you answer these questions, and why would you answer them that way? Our answers strongly influence what we believe is within the purview of enterprise architecture, how we address that scope, and what we imagine we can accomplish by doing so.

Len Fehskens is Vice President of Skills and Capabilities at The Open Group. He is responsible for The Open Group’s activities relating to the professionalization of the discipline of enterprise architecture. Prior to joining The Open Group, Len led the Worldwide Architecture Profession Office for HP Services at Hewlett-Packard. Len is based in the US.

49 Comments

Filed under Enterprise Architecture

Thoughts on reorienting Enterprise Architecture

By Raghuraman Krishnamurthy, Cognizant Technology Solutions

My last post generated an interesting comment from Tom, who found resonance in one of the thoughts (“EA should be a wider discipline”) that I had mentioned: the need to look at the world and learn from the leaner supply chain efficiencies realized by the manufacturing segment. In an interesting post on securing global technology supply chains, Andras Szakal of IBM talks about taking cues from industry associations. An effort like this that attempts to learn from the established efficiencies of other supply chains will be a great step forward.

In the flat world, innovations can occur anywhere and enterprises must look at how to take best advantage of that. The emergence of the Internet and richer channels of communication have created new fundamental forces that any enterprise needs to contend with:

  • Getting closer to your customer
  • Innovations in service/product offerings
  • Achieve high operational efficiency
  • Building of brand perception: Regulatory/social/environmental consciousness

Taking the case of the pharmaceutical industry, one can see how all the above forces have resulted in dramatic transformations. For pharmaceuticals, where the earlier customer segments were the prescribing physician and the payers, a new brand segment has emerged: the patients. Technology advances have enabled formation of virtual communities where the efficacies of drugs are debated by patients, and this has created powerful brand perception that pharmaceuticals cannot afford to ignore. Pharmaceuticals and providers are coming together to create innovative service offerings and are beginning to experiment with outcome-based payment plans. Regulators and the public demand more transparency in the clinical trial processes and sharing of safety data. The need for higher operational efficiency has resulted in more and more outsourcing of business processes. This has created a fluxed enterprise boundary as many competencies are outside the traditional realm of the enterprise.

Successful EA needs to demonstrate a deep understanding of these fundamental forces. Whatever modeling or tools or methodologies one may adapt for EA, there should be a connect to these fundamental forces that shape the thinking of the enterprise. I think it is very important that we be aware of the forces of influence of our enterprises and position EA to help manage these forces. Of course, it is a long call to have practical demonstrations of this, but an effort in this direction demonstrates staying relevant and contributing in a powerful way. EA is truly at the cusp of transformation.

Enterprise Architecture will be a topic of discussion at The Open Group India Conference next week in Chennai (March 7), Hyderabad (March 9) and Pune (March 11). Join us for best practices and case studies in the areas of Enterprise Architecture, Security, Cloud and Certification, presented by preeminent thought leaders in the industry.

Raghuraman Krishnamurthy works as a Principal Architect at Cognizant Technology Solutions and is based in India. He can be reached at Raghuraman.krishnamurthy2@cognizant.com.

3 Comments

Filed under Enterprise Architecture