Tag Archives: EA

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 ArchiMate®, Business Architecture, Certifications, Conference, Cybersecurity, Enterprise Architecture, Enterprise Transformation, FACE™, Information security, TOGAF®, Uncategorized

Learn How Enterprise Architects Can Better Relate TOGAF and DoDAF to Bring Best IT Practices to Defense Contracts

By Dana Gardner, Interarbor Solutions

This BriefingsDirect thought leadership interview comes in conjunction with The Open Group Conference in Washington, D.C., beginning July 16. The conference will focus on how Enterprise Architecture (EA), enterprise transformation, and securing global supply chains.

We’re joined by one of the main speakers at the July 16 conference, Chris Armstrong, President of Armstrong Process Group, to examine how governments in particular are using various frameworks to improve their architectural planning and IT implementations.

Armstrong is an internationally recognized thought leader in EA, formal modeling, process improvement, systems and software engineering, requirements management, and iterative and agile development.

He represents the Armstrong Process Group at the Open Group, the Object Management Group (OMG), and Eclipse Foundation. Armstrong also co-chairs The Open Group Architectural Framework (TOGAF®), and Model Driven Architecture (MDA) process modeling efforts, and also the TOGAF 9 Tool Certification program, all at The Open Group.

At the conference, Armstrong will examine the use of TOGAF 9 to deliver Department of Defense (DoD) Architecture Framework or DoDAF 2 capabilities. And in doing so, we’ll discuss how to use TOGAF architecture development methods to drive the development and use of DoDAF 2 architectures for delivering new mission and program capabilities. His presentation will also be Livestreamed free from The Open Group Conference. The full podcast can be found here.

Here are some excerpts:

Gardner: TOGAF and DoDAF, where have they been? Where are they going? And why do they need to relate to one another more these days?

Armstrong: TOGAF [forms] a set of essential components for establishing and operating an EA capability within an organization. And it contains three of the four key components of any EA.

First, the method by which EA work is done, including how it touches other life cycles within the organization and how it’s governed and managed. Then, there’s a skills framework that talks about the skills and experiences that the individual practitioners must have in order to participate in the EA work. Then, there’s a taxonomy framework that describes the semantics and form of the deliverables and the knowledge that the EA function is trying to manage.

One-stop shop

One of the great things that TOGAF has going for it is that, on the one hand, it’s designed to be a one-stop shop — namely providing everything that a end-user organization might need to establish an EA practice. But it does acknowledge that there are other components, predominantly in the various taxonomies and reference models, that various end-user organizations may want to substitute or augment.

It turns out that TOGAF has a nice synergy with other taxonomies, such as DoDAF, as it provides the backdrop for how to establish the overall EA capability, how to exploit it, and put it into practice to deliver new business capabilities.

Frameworks, such as DoDAF, focus predominantly on the taxonomy, mainly the kinds of things we’re keeping track of, the semantics relationships, and perhaps some formalism on how they’re structured. There’s a little bit of method guidance within DoDAF, but not a lot. So we see the marriage of the two as a natural synergy.

Gardner: So their complementary natures allows for more particulars on the defense side, but the overall TOGAF looks at the implementation method and skills for how this works best. Is this something new, or are we just learning to do it better?

Armstrong: I think we’re seeing the state of industry advance and looking at trying to have the federal government, both United States and abroad, embrace global industry standards for EA work. Historically, particularly in the US government, a lot of defense agencies and their contractors have often been focusing on a minimalistic compliance perspective with respect to DoDAF. In order to get paid for this work or be authorized to do this work, one of our requirements is we must produce DoDAF.

People are doing that because they’ve been commanded to do it. We’re seeing a new level of awareness. There’s some synergy with what’s going on in the DoDAF space, particularly as it relates to migrating from DoDAF 1.5 to DoDAF 2.

Agencies need some method and technique guidance on exactly how to come up with those particular viewpoints that are going to be most relevant, and how to exploit what DoDAF has to offer, in a way that advances the business as opposed to just solely being to conforming or compliant?

Gardner: Have there been hurdles, perhaps culturally, because of the landscape of these different companies and their inability to have that boundary-less interaction. What’s been the hurdle? What’s prevented this from being more beneficial at that higher level?

Armstrong: Probably overall organizational and practitioner maturity. There certainly are a lot of very skilled organizations and individuals out there. However, we’re trying to get them all lined up with the best practice for establishing an EA capability and then operating it and using it to a business strategic advantage, something that TOGAF defines very nicely and which the DoDAF taxonomy and work products hold in very effectively.

Gardner: Help me understand, Chris. Is this discussion that you’ll be delivering on July 16 primarily for TOGAF people to better understand how to implement vis-à-vis, DoDAF, is this the other direction, or is it a two-way street?

Two-way street

Armstrong: It’s a two-way street. One of the big things that particularly the DoD space has going for it is that there’s quite a bit of maturity in the notion of formally specified models, as DoDAF describes them, and the various views that DoDAF includes.

We’d like to think that, because of that maturity, the general TOGAF community can glean a lot of benefit from the experience they’ve had. What does it take to capture these architecture descriptions, some of the finer points about managing some of those assets. People within the TOGAF general community are always looking for case studies and best practices that demonstrate to them that what other people are doing is something that they can do as well.

We also think that the federal agency community also has a lot to glean from this. Again, we’re trying to get some convergence on standard methods and techniques, so that they can more easily have resources join their teams and immediately be productive and add value to their projects, because they’re all based on a standard EA method and framework.

One of the major changes between DoDAF 1 and DoDAF 2 is the focusing on fitness for purpose. In the past, a lot of organizations felt that it was their obligation to describe all architecture viewpoints that DoDAF suggests without necessarily taking a step back and saying, “Why would I want to do that?”

So it’s trying to make the agencies think more critically about how they can be the most agile, mainly what’s the least amount of architecture description that we can invest and that has the greatest possible value. Organizations now have the discretion to determine what fitness for purpose is.

Then, there’s the whole idea in DoDAF 2, that the architecture is supposed to be capability-driven. That is, you’re not just describing architecture, because you have some tools that happened to be DoDAF conforming, but there is a new business capability that you’re trying to inject into the organization through capability-based transformation, which is going to involve people, process, and tools.

One of the nice things that TOGAF’s architecture development method has to offer is a well-defined set of activities and best practices for deciding how you determine what those capabilities are and how you engage your stakeholders to really help collect the requirements for what fit for purpose means.

Gardner: As with the private sector, it seems that everyone needs to move faster. I see you’ve been working on agile development. With organizations like the OMG and Eclipse is there something that doing this well — bringing the best of TOGAF and DoDAF together — enables a greater agility and speed when it comes to completing a project?

Different perspectives

Armstrong: Absolutely. When you talk about what agile means to the general community, you may get a lot of different perspectives and a lot of different answers. Ultimately, we at APG feel that agility is fundamentally about how well your organization responds to change.

If you take a step back, that’s really what we think is the fundamental litmus test of the goodness of an architecture. Whether it’s an EA, a segment architecture, or a system architecture, the architects need to think thoughtfully and considerately about what things are almost certainly going to happen in the near future. I need to anticipate, and be able to work these into my architecture in such a way that when these changes occur, the architecture can respond in a timely, relevant fashion.

We feel that, while a lot of people think that agile is just a pseudonym for not planning, not making commitments, going around in circles forever, we call that chaos, another five letter word. But agile in our experience really demands rigor, and discipline.

Of course, a lot of the culture of the DoD brings that rigor and discipline to it, but also the experience that that community has had, in particular, of formally modeling architecture description. That sets up those government agencies to act agilely much more than others.

Gardner: Do you know of anyone that has done it successfully or is in the process? Even if you can’t name them, perhaps you can describe how something like this works?

Armstrong: First, there has been some great work done by the MITRE organization through their work in collaboration at The Open Group. They’ve written a white paper that talks about which DoDAF deliverables are likely to be useful in specific architecture development method activities. We’re going to be using that as a foundation for the talk we’re going to be giving at the conference in July.

The biggest thing that TOGAF has to offer is that a nascent organization that’s jumping into the DoDAF space may just look at it from an initial compliance perspective, saying, “We have to create an AV-1, and an OV-1, and a SvcV-5,” and so on.

Providing guidance

TOGAF will provide the guidance for what is EA. Why should I care? What kind of people do I need within my organization? What kind of skills do they need? What kind of professional certification might be appropriate to get all of the participants up on the same page, so that when we’re talking about EA, we’re all using the same language?

TOGAF also, of course, has a great emphasis on architecture governance and suggests that immediately, when you’re first propping up your EA capability, you need to put into your plan how you’re going to operate and maintain these architectural assets, once they’ve been produced, so that you can exploit them in some reuse strategy moving forward.

So, the preliminary phase of the TOGAF architecture development method provides those agencies best practices on how to get going with EA, including exactly how an organization is going to exploit what the DoDAF taxonomy framework has to offer.

Then, once an organization or a contractor is charged with doing some DoDAF work, because of a new program or a new capability, they would immediately begin executing Phase A: Architecture Vision, and follow the best practices that TOGAF has to offer.

Just what is that capability that we’re trying to describe? Who are the key stakeholders, and what are their concerns? What are their business objectives and requirements? What constraints are we going to be placed under?

Part of that is to create a high-level description of the current or baseline architecture descriptions, and then the future target state, so that all parties have at least a coarse-grained idea of kind of where we’re at right now, and what our vision is of where we want to be.

Because this is really a high level requirements and scoping set of activities, we expect that that’s going to be somewhat ambiguous. As the project unfolds, they’re going to discover details that may cause some adjustment to that final target.

Internalize best practices

So, we’re seeing defense contractors being able to internalize some of these best practices, and really be prepared for the future so that they can win the greatest amount of business and respond as rapidly and appropriately as possible, as well as how they can exploit these best practices to affect greater business transformation across their enterprises.

Gardner: We mentioned that your discussion on these issues, on July 16 will be Livestreamed for free, but you’re also doing some pre-conference and post-conference activities — webinars, and other things. Tell us how this is all coming together, and for those who are interested, how they could take advantage of all of these.

Armstrong: We’re certainly very privileged that The Open Group has offered this as opportunity to share this content with the community. On Monday, June 25, we’ll be delivering a webinar that focuses on architecture change management in the DoDAF space, particularly how an organization migrates from DoDAF 1 to DoDAF 2.

I’ll be joined by a couple of other people from APG, David Rice, one of our Principal Enterprise Architects who is a member of the DoDAF 2 Working Group, as well as J.D. Baker, who is the Co-chair of the OMG’s Analysis and Design Taskforce, and a member of the Unified Profile for DoDAF and MODAF (UPDM) work group, a specification from the OMG.

We’ll be talking about things that organizations need to think about as they migrate from DoDAF 1 to DoDAF 2. We’ll be focusing on some of the key points of the DoDAF 2 meta-model, namely the rearrangement of the architecture viewpoints and the architecture partitions and how that maps from the classical DoDAF 1.5 viewpoint, as well as focusing on this notion of capability-driven architectures and fitness for purpose.

We also have the great privilege after the conference to be delivering a follow-up webinar on implementation methods and techniques around advanced DoDAF architectures. Particularly, we’re going to take a closer look at something that some people may be interested in, namely tool interoperability and how the DoDAF meta-model offers that through what’s called the Physical Exchange Specification (PES).

We’ll be taking a look a little bit more closely at this UPDM thing I just mentioned, focusing on how we can use formal modeling languages based on OMG standards, such as UML, SysML, BPMN, and SoaML, to do very formal architectural modeling.

One of the big challenges with EA is, at the end of the day, EA comes up with a set of policies, principles, assets, and best practices that talk about how the organization needs to operate and realize new solutions within that new framework. If EA doesn’t have a hand-off to the delivery method, namely systems engineering and solution delivery, then none of this architecture stuff makes a bit of a difference.

Driving the realization

We’re going to be talking a little bit about how DoDAF-based architecture description and TOGAF would drive the realization of those capabilities through traditional systems, engineering, and software development method.

************

For more information on The Open Group’s upcoming conference in Washington, D.C., please visit: http://www.opengroup.org/dc2012

Dana Gardner is president and principal analyst at Interarbor Solutions, an enterprise IT analysis, market research, and consulting firm. Gardner, a leading identifier of software and Cloud productivity trends and new IT business growth opportunities, honed his skills and refined his insights as an industry analyst, pundit, and news editor covering the emerging software development and enterprise infrastructure arenas for the last 18 years.

Comments Off

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

Open CA Candidate Profile: An Interview with Andrey Zaychikov

By Steve Philp, The Open Group

Andrey Zaychikov is CIO and Chief Enterprise Architect Ministry of Sport, Tourism and Youth Policy for the Russian Federation

In February 2012, Andrey Zaychikov became the first Russian to go through the Open CA program via the direct route. He flew to London Heathrow from Moscow to attend the certification board at a local hotel near Heathrow airport and successfully achieved Master Open CA status. We asked him why he wanted to get Open CA certified and how he found the process.

Can you tell us something about yourself in terms of your background and career to date?

I started my career as a software developer with a Master’s degree in computer science and more than five years experience in creating applications using C, C++ and .NET. In those days I was eager to understand how to define the solution requirements and design its implementation, how to deal with the risks, how to organize the communication with customers in a most effective manner. I applied different approaches based on Booch-2 (in early days), then UML etc. They were quite effective (of course, if adopted to the needs of the particular projects and being common-sense) especially talking about small or medium silo applications.

In 2007, I was put in charge of a huge project involving more than 300 organizations within the enterprise and affecting 80 percent of its operational activities. The enormous complexity of this project forced me to look for the other ways to handle it. I found out that enterprise architecture was the only solution to deal with that issue. That was the start of my career as an Enterprise Architect.

Why did you decide to go for Open CA certification?

On the one hand, I had some problems with the quality of assessment of my professional skills and assessment of my approach to defining and governing enterprise architectures, and on the other hand it was a real chance to demonstrate the level of my personal skills and acquirement to the customers, employees, colleagues and competitors.  Besides, it is a good line in a CV to refer to and it will help to boost my career.

Why is Open CA different from other IT certifications that you have previously been involved with?

I chose Open CA Certification Program because it is:

  • Really vendor, country and methods neutral
  • Based on best practices
  • A great challenge to succeed as an Enterprise Architect
  • A unique chance to assess one’s personal skills and acquirement against the world’s best professionals
  • It is linked to a certified professional and not to a company
  • It helps to determine one’s strengths and weaknesses
  • It is instrumental in building one’s personal development and educational plan
  • It is one of the most prestigious enterprise architecture certifications.

In fact, as I thought, it could really help me to define my place in the world of enterprise architecture and to look at myself from another point of view. It helps not only to assess one’s methodological, technical or business skills but also to assess one’s common approach to work in the terms of enterprise architecture.

How did you prepare for Open CA certification?

My preparation was organized in a step-by-step manner.  First of all, I read the Conformance Requirements and a sample package in order to understand what I should do at the first stage of the certification. I used a  self-assessment tool at this stage as well. Then, I completed the experience profiles because it seemed to me to be far easier to write the profiles rather than the questions section first. I wrote the experience profiles in Russian, my native language and then translated them into English. Therefore, it took me approximately twice as much time as estimated by the Certification Board.

Then I answered the questions in the sections. This time I did not translate them – I just wrote the responses straight in English.

After that I did several reviews of my package in order to squeeze it into 50 pages, simplified some responses and diagrams.

While reviewing my package I tried to conform my package with the requirements and made every response clear to the people who are not aware of the current vertical industry and specific project situation. I watched some sitcoms and read a lot of fiction in English for language practice since I did not use English at work.

Having received the review of my package from The Open Group, I made some minor changes in order to clear up some issues.

Then I began preparation for the interview. I read carefully the certification board member handbook to figure out what the Board might be interested in during the interview. I reviewed my package again trying to ask myself as many questions as I could and answered them mentally, in other words, I tried being in interviewers’ shoes.

Then, taking into consideration the time left before the interview, I chose the most important questions and answered only them in English.

Two days before the interview I read thoroughly my package and the questions again. I arrived to London two days before the interview, again in order to practice the language a bit and not to have the linguistic shock.

What benefits do you think having this certification will bring you?

Despite of the fact that the Open CA certification program is not really well known in Russia, it has already brought me some recognition at Russian IT market, especially among vendors as an excellent and unique specialist. Besides, it really helped me to interact with international community. I think it will speed up my career as a CIO and EA in the near future.

What are your plans for future certifications?

I am planning to progress to Open CA Level 3 in a couple of years. I am thinking over PMBOK certification as well, as I often had to fulfill the role of the project manager in some large projects. Plus, I would like to take TOGAF 9 Certification as my TOGAF 8.1.1 has expired and I am going to continue working on my PhD.

Steve Philp is the Marketing Director for the Open CA and Open CITS certification programs 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.

2 Comments

Filed under Certifications, Enterprise Architecture, Professional Development, Uncategorized

Three Things I Wish I Had Known When I Started My Career

By Leonard Fehskens, The Open Group

It being the time of year for commencement speeches, Patty Donovan asked if I could offer some advice to graduates entering the Enterprise Architecture profession.

She specifically asked what three things I wished I had known when I began my career, and it’s impossible to resist the setup.  I wish I had known:

1)   What stocks to buy and sell when

2)   Which managers at what companies to work for

3)   Which personal relationships to pursue and which to avoid

Had I known these things, my life would likely have been free of much unproductive stress.

OK; that’s not really helpful advice; these aren’t things that one can actually know in advance.

But there are some things that I sort of knew when I got out of school, that in retrospect have proven to be far more important than I imagined at the time.  They are:

1)   Things, especially big things, only get done by collaborating with other people.

2)   Be open to other perspectives.

3)   Nothing in the real world is linear or one-dimensional.

4)   You have to be able to commit, and be prepared to deal with the consequences.

Let’s explore each of these in turn.

Things, especially big things, only get done by collaborating with other people

This seems pretty obvious, but we never seem to take it into account.  Unless you’re a genius of staggering magnitude, your success is going to be largely dependent on your ability to work with other people.

If you majored in some aspect of information systems, unless you minored in psychology or sociology it’s unlikely you took more than one or two elective courses in one or the other.  If you’re lucky, the company you work for will send you on a two or three day “team building exercise” every few years.  If you’re really lucky, you may get sent to a week-long “executive development program” in leadership or “organizational dynamics.”  These sorts of development programs used to be much more common, but are now much harder to cost-justify.  My experience with these things was that they were often interesting, though some of the exercises were a bit contrived.  But the key problem was that whatever one might learn from them was easily forgotten without any subsequent coaching and reinforcement, washed out by the implicit assumption that how to collaborate as part of team is something we all knew how to do intuitively.

So what we’re left with is “learning by doing,” and it’s clear from experience that this basically means picking up habits that, without expert coaching, will be a random mix of both good and bad.  What can we do about this?

Most organizations have an HR policy about staff development plans, and while people are rarely held accountable for not carrying out such a plan, a sensible request to take advantage of the policy will also rarely be refused.  Don’t neglect any opportunity you get to develop your “soft skills” or “people skills.”

 Be open to other perspectives

A thoughtfully open mind—the ability to recognize good ideas and not so good ideas, especially when they’re someone else’s ideas—is probably one of the most useful and most difficult faculties to develop.

It’s a cliché that truly effective communication is difficult.  In practice I have found this often means that we don’t understand why someone takes a position different from ours, and without that understanding, it is too easy to discount that position.  This is compounded by our predisposition, especially among techno-dweeb-weenies, to focus on differences rather than similarities, something Freud called the “narcissism of small differences.”

Fred Brooks (“The Mythical ManMonth,” “The Design of Design”) has long argued that the chief or lead architect is responsible for ensuring the “conceptual integrity” of a design, but this doesn’t mean that all the ideas have to come from that architect.  Nobody has all the answers.  It is the architect’s responsibility to synthesize worthwhile contributions, wherever they come from, into an integrated whole.

 Nothing in the real world is linear or one-dimensional

When I moved on to a new position after leading an architecture team for several years at Digital Equipment Corporation, the team gave me two rubber stamps as a token of their appreciation.  One said “It depends …”, and the other said “Yes, but …”.

Though it’s almost never possible, or sensible, to rank anything non-trivial on a single linear scale, we try to do this all the time.  Simple models of complex things do not make those things simple.  Acting as if they do is called “magical thinking,” for a reason.

So there’s almost never going to be a clearly best answer.  The best we can do is understand what the tradeoffs are, and make them knowingly and deliberately.

 You have to be able to commit, and be prepared to deal with the consequences

Each of the above three lessons tends to complicate things, and complications tend to delay decision-making and commitment to a particular way forward.  While successful architects understand that delayed binding is often an effective design strategy, they also understand that they will never have all the information they need to make a fully informed decision, and finally, and most importantly, that you can’t postpone decisions indefinitely.  They seem to have a knack for understanding which decisions really need to be made when, and how to connect the information they do have into a coherent context for making those decisions.

But they also have contingency plans, and ways to tell as early as possible whether they need to use them.  In a genuinely supportive environment, it will be OK to reconsider a decision, but only if you do so as soon as you realize that you need to.

So, don’t make decisions any sooner than they must be made, but don’t make them any later either, and make sure you don’t “paint yourself into a corner.”

 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.

1 Comment

Filed under Enterprise Architecture, Professional Development

Enterprise Architects and Paradigm Shifts

By Stuart Boardman, KPN

It’s interesting looking back at what people have written over the course of the year and seeing which themes appear regularly in their blogs. I thought I’d do the same with my own posts for The Open Group and see whether I could pull some of it together. I saw that the recurring themes for me have been dealing with uncertainty, the changing nature of the enterprise and the influence of information technology from outside the enterprise – and all of this in relation to the practice of enterprise architecture. I also explored the mutual influences these themes have on each other.

Unsurprisingly I’m not alone in picking up on these themes. At the risk of offending anyone I don’t mention, I note that Serge Thorn, Raghuraman Krishnamurthy and Len Fehskens have given their own perspectives on The Open Group’s Blog on some or all of these themes. And of course there’s plenty of writing on these themes going on in the blogosphere at large. In one sense I think writing about this is part of a process of trying to understand what’s going on in the world.

After some reflection, it seems to me that all of this converges in what tends to be called ”social business.” For better or worse, there is no fixed definition of the term. I would say it describes a way of working where, both within and across organizations, hierarchies and rules are being replaced by networks and collaboration. The concept of the enterprise in such a system is then definitively extended to include a whole ecosystem of customers and suppliers as well as investors and beneficiaries. Any one organization is just a part of the enterprise – a stakeholder. And of course the enterprise will look different dependent on the viewpoint of a particular stakeholder. That should be a familiar concept anyway for an enterprise architect. That one participant can be a stakeholder in multiple enterprises is not really new – it’s just something we now have no choice but to take into account.

Within any one organization, social business means that creativity and strategy development takes place at and across multiple levels. We can speak of networked, podular or fractal forms of organization. It also means a lot of other things with wider economic, social and political implications but that’s not my focus here.

Another important aspect is the relationship with newer developments in information and communication technology. We can’t separate social business from the technology which has helped it to develop and which in turn is stimulated by its existence and demands. I don’t mean any one technology and I won’t even insist on restricting it to information technology. But it’s clear that there is at least a high degree of synergy between newer IT developments and social business. In other words, the more an organization becomes a social business, the more its business will involve the use of information technology – not as a support function but as an essential part of how it does its business.  Moreover exactly this usage of IT is not and cannot be (entirely) under its own control.

A social business therefore demonstrates, in all aspects of the enterprise, fuzzy boundaries and a higher level of what I call entropy (uncertainty, rate of change, sensitivity to change). It means we need new ways of dealing with complexity, which fortunately is a topic a lot of people are looking at. It means that simplicity is not in every case a desirable goal and that, scary as it may seem, we may actually need to encourage entropy (in some places) in order to develop the agility to respond to change – effectively and without making any unnecessary long term assumptions.

So, if indeed the world is evolving to such a state, what can enterprise architects do to help their own organizations become successful social businesses (social governments – whatever)?

Enterprise Architecture is a practice that is founded in communication. To support and add value to that communication we have developed analysis methods and frameworks, which help us model what we learn and, in turn, communicate the results. Enterprise Architects work across organizations to understand how the activities of the participants relate to the strategy of the organization and how the performance of each person/group’s activities can optimally support and reinforce everyone else’s. We don’t do their work for them and don’t, if we do our work properly, have any sectional interests. We are the ultimate generalists, specialized in bringing together all those aspects, in which other people are the experts. We’re therefore ideally placed to facilitate the development of a unified vision and a complementary set of practices. OK, that sounds a bit idealistic. We know reality is never perfect but, if we don’t have ideals, we’d be hypocrites to be doing this work anyway. Pragmatism and ideals can be a positive combination.

Yes, there’s plenty of work to do to adapt our models to this new reality. Our goals, the things we try to achieve with EA will not be different. In some significant aspects, the results will be – if only because of the scope and diversity of the enterprise. We’ll certainly need to produce some good example EA artifacts to show what these results will look like. I can see an obvious impact in business architecture and in governance – most likely other areas too. But the issues faced in governance may be similar to those being tackled by The Open Group’s Cloud Governance project. And business architecture is long due for expansion outside of the single organization, so there’s synergy there as well. We can also look outside of our own community for inspiration – in the area of complexity theory, in business modeling, in material about innovation and strategy development and in economic and even political thinking about social business.

We’ll also be faced with organizational challenges. EA has for too long and too often been seen as the property of the IT department. That’s always been a problem anyway, but to face the challenges of social business, EA must avoid the slightest whiff of sectional interest and IT centrism. And, ironically, the best hope for the IT department in this scary new world may come from letting go of what it does not need to control and taking on a new role as a positive enabler of change.

There could hardly be a more appropriate time to be working on TOGAF Next. What an opportunity!

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. 

5 Comments

Filed under Business Architecture, Cloud, Cloud/SOA, Enterprise Architecture, Enterprise Transformation, Semantic Interoperability

Capgemini’s CTO on How Cloud Computing Exposes the Duality Between IT and Business Transformation

By Dana Gardner, Interarbor Solutions

This BriefingsDirect thought leadership interview comes in conjunction with The Open Group Conference this month in San Francisco.

The conference will focus on how IT and enterprise architecture support enterprise transformation. Speakers in conference events will also explore the latest in service oriented architecture (SOA), cloud computing, and security.

We’re now joined by one of the main speakers, Andy Mulholland, the Global Chief Technology Officer and Corporate Vice President at Capgemini. In 2009, Andy was voted one of the top 25 most influential CTOs in the world by InfoWorld. And in 2010, his CTO Blog was voted best blog for business managers and CIOs for the third year running by Computer Weekly.

Capgemini is about to publish a white paper on cloud computing. It draws distinctions between what cloud means to IT, and what it means to business — while examining the complex dual relationship between the two.

As a lead-in to his Open Group conference presentation on the transformed enterprise, Andy draws on the paper and further drills down on one of the decade’s hottest technology and business trends, cloud computing, and how it impacts business and IT. The interview is moderated by Dana Gardner, Principal Analyst at Interarbor Solutions. The full podcast can be found here.

Here are some excerpts:

Gardner: Why do business people think they have a revolution on their hands, while IT people look cloud computing as an evolution of infrastructure efficiency?

Mulholland: We define the role of IT and give it the responsibility and the accountability in the business in a way that is quite strongly related to internal practice. It’s all about how we manage the company’s transactions, how we reduce the cost, how we automate business process,and generally try to make our company a more efficient internal operator.

When you look at cloud computing through that set of lenses, you’re going to see … the technologies from cloud computing, principally virtualization, [as] ways to improve how you deliver the current server-centric, application-centric environment.

However, business people … reflect on it in terms of the change in society and the business world, which we all ought to recognize because that is our world, around the way we choose what we buy, how we choose to do business with people, how we search more, and how we’ve even changed that attitude.

Changed our ways

There’s a whole list of things that we simply just don’t do anymore because we’ve changed the way we choose to buy a book, the way we choose and listen to music and lots of other things.

So we see this as a revolution in the market or, more particularly, a revolution in how cloud can serve in the market, because everybody uses some form of technology.

So then the question is not the role of the IT department and the enterprise — it’s the role technology should be playing in their extended enterprise in doing business.

Gardner: What do we need to start doing differently?

Mulholland: Let’s go to a conversation this morning with a client. It’s always interesting to touch reality. This particular client is looking at the front end of a complex ecosystem around travel, and was asked this standard question by our account director: Do you have a business case for the work we’re discussing?

The reply from the CEO is very interesting. He fixed him with a very cold glare and he said, “If you were able to have 20 percent more billable hours without increasing your cost structure, would you be bothered to even think about the business case?”

The answer in that particular case was they were talking about 10,000 more travel instances or more a year — with no increase in their cost structure. In other words, their whole idea was there was nothing to do with cost in it. Their argument was in revenue increase, market share increase, and they thought that they would make better margins, because it would actually decrease their cost base or spread it more widely.

That’s the whole purpose of this revolution and that’s the purpose the business schools are always pushing, when they talk about innovative business models. It means innovate your business model to look at the market again from the perspective of getting into new markets, getting increased revenue, and maybe designing things that make more money.

Using technology externally

We’re always hooked on this idea that we’ve used technology very successfully internally, but now we should be asking the question about how we’re using technology externally when the population as a whole uses that as their primary method of deciding what they’re going to buy, how they’re going to buy it, when they’re going to buy it, and lots of other questions.

… A popular book recently has been The Power of Pull, and the idea is that we’re really seeing a decentralization of the front office in order to respond to and follow the market and the opportunities and the events in very different ways.

The Power of Pull says that I do what my market is asking me and I design business process or capabilities to be rapidly orchestrated through the front office around where things want to go, and I have linkage points, application programming interface (API) points, where I take anything significant and transfer it back.

But the real challenge is — and it was put to me today in the client discussion — that their business was designed around 1970 computer systems, augmented slowly around that, and they still felt that. Today, their market and their expectations of the industry that they’re in were that they would be designed around the way people were using their products and services and the events and that they had to make that change.

To do that, they’re transformed in the organization, and that’s where we start to spot the difference. We start to spot the idea that your own staff, your customers, and other suppliers are all working externally in information, process, and services accessible to all on an Internet market or architecture.

So when we talk about business architecture, it’s as relevant today as it ever was in terms of interpreting a business.

Set of methodologies

But when we start talking about architecture, The Open Group Architectural Framework (TOGAF) is a set of methodologies on the IT side — the closed-coupled state for a designed set of principles to client-server type systems. In this new model, when we talk about clouds, mobility, and people traveling around and connecting by wireless, etc., we have a stateless loosely coupled environment.

The whole purpose of The Open Group is, in fact, to help devise new ways for being able to architect methods to deliver that. That’s what stands behind the phrase, “a transformed enterprise.”

… If we go back to the basic mission of The Open Group, which is boundarylessness of this information flow, the boundary has previously been defined by a computer system updating another computer system in another company around traditional IT type procedural business flow.

Now, we’re talking about the idea that the information flow is around an ecosystem in an unstructured way. Not a structured file-to-file type transfer, not a structured architecture of who does what, when, and how, but the whole change model in this is unstructured.

Gardner: It’s important to point out here, Andy, that the stakes are relatively high. Who in the organization can be the change agent that can make that leap between the duality view of cloud that IT has, and these business opportunists?

Mulholland: The CEOs are quite noticeably reading the right articles, hearing the right information from business schools, etc., and they’re getting this picture that they’re going to have new business models and new capabilities.

So the drive end is not hard. The problem that is usually encountered is that the IT department’s definition and role interferes with them being able to play the role they want.

What we’re actually looking for is the idea that IT, as we define it today, is some place else. You have to accept that it exists, it will exist, and it’s hugely important. So please don’t take those principles and try to apply them outside.

The real question here is when you find those people who are doing the work outside — and I’ve yet to find any company where it hasn’t been the case — and the question should be how can we actually encourage and manage that innovation sensibly and successfully?

What I mean by that is that if everybody goes off and does their own thing, once again, we’ll end up with a broken company. Why? Because their whole purpose as an enterprises is to leverage success rapidly. If someone is very successful over there, you really need to know, and you need to leverage that again as rapidly as you can to run the rest of the organization. If it doesn’t work, you need to stop it quickly.

Changing roles

In models of the capabilities of that, the question is where is the government structure? So we hear titles like Chief Innovation Officer, again, slightly surprising how it may come up. But we see the model coming both ways. There are reforming CIOs for sure, who have recognized this and are changing their role and position accordingly, sometimes formally, sometimes informally.

The other way around, there are people coming from other parts of the business, taking the title and driving them. I’ve seen Chief Strategy Officers taking the role. I’ve seen the head of sales and marketing taking the role.

Certainly, recognizing the technology possibilities should be coming from the direction of the technology capabilities within the current IT department. The capability of what that means might be coming differently. So it’s a very interesting balance at the moment, and we don’t know quite the right answer.

What I do know is that it’s happening, and the quick-witted CIOs are understanding that it’s a huge opportunity for them to fix their role and embrace a new area, and a new sense of value that they can bring to their organization.

Gardner: Returning to the upcoming Capgemini white paper, it adds a sense of urgency at the end on how to get started. It suggests that you appoint a leader, but a leader first for the inside-out element of cloud and transformation and then a second leader, a separate leader perhaps, for that outside-in or reflecting the business transformation and the opportunity for what’s going on in the external business and markets. It also suggests a strategic road map that involves both business and technology, and then it suggests getting a pilot going.

How does this transition become something that you can manage?

Mulholland: The question is do you know who is responsible. If you don’t, you’d better figure out how you’re going to make someone responsible, because in any situation, someone has to be deciding what we’re going to do and how we’re going to do it.

Having defined that, there are very different business drivers, as well as different technology drivers, between the two. Clearly, whoever takes those roles will reflect a very different way that they will have to run that element. So a duality is recognized in that comment.

On the other hand, no business can survive by going off in half-a-dozen directions at once. You won’t have the money. You won’t have the brand. You won’t have anything you’d like. It’s simply not feasible.

So, the object of the strategic roadmap is to reaffirm the idea of what kind of business we’re trying to be and do. That’s the glimpse of what we want to achieve.

There has to be a strategy. Otherwise, you’ll end up with way too much decentralization and people making up their own version of the strategy, which they can fairly easily do and fairly easily mount from someone else’s cloud to go and do it today.

So the purpose of the duality is to make sure that the two roles, the two different groups of technology, the two different capabilities they reflect to the organization, are properly addressed, properly managed, and properly have a key authority figure in charge of them.

Enablement model

The business strategy is to make sure that the business knows how the enablement model that these two offer them is capable of being directed to where the shareholders will make money out of the business, because that is ultimately that success factor they’re looking for to drive them forward.

************

If you are interested in attending The Open Group’s upcoming conference, please register here: http://www3.opengroup.org/event/open-group-conference-san-francisco/registration

Dana Gardner is president and principal analyst at Interarbor Solutions, an enterprise IT analysis, market research, and consulting firm. Gardner, a leading identifier of software and cloud productivity trends and new IT business growth opportunities, honed his skills and refined his insights as an industry analyst, pundit, and news editor covering the emerging software development and enterprise infrastructure arenas for the last 18 years.

3 Comments

Filed under Cloud, Cloud/SOA, Enterprise Transformation, Semantic Interoperability

MIT’s Ross on How Enterprise Architecture and IT More Than Ever Lead to Business Transformation

By Dana Gardner, Interarbor Solutions

This BriefingsDirect thought leadership interview comes in conjunction with The Open Group Conference this month in San Francisco.

The conference will focus on how IT and enterprise architecture support enterprise transformation. Speakers in conference events will also explore the latest in service oriented architecture (SOA), cloud computing, and security.

We’re now joined by of the main speakers, Jeanne Ross, Director and Principal Research Scientist at the MIT Center for Information Systems Research. Jeanne studies how firms develop competitive advantage through the implementation and reuse of digitized platforms.

She is also the co-author of three books: IT Governance: How Top Performers Manage IT Decision Rights for Superior Results, Enterprise Architecture As Strategy: Creating a Foundation for Business Execution, and IT Savvy: What Top Executives Must Know to Go from Pain to Gain.

As a lead-in to her Open Group presentation on how adoption of enterprise architecture (EA) leads to greater efficiencies and better business agility, Ross explains how enterprise architects have helped lead the way to successful business transformations. The interview is moderated by Dana Gardner, Principal Analyst at Interarbor Solutions. The full podcast can be found here.

Here are some excerpts:

Gardner: How you measure or determine that enterprise architects and their practices are intrinsic to successful business transformations?

Ross: That’s a great question. Today, there remains kind of a leap of faith in recognizing that companies that are well-architected will, in fact, perform better, partly because you can be well-architected and perform badly. Or if we look at companies that are very young and have no competitors, they can be very poorly architected and achieve quite remarkably in the marketplace.

But what we can ascribe to architecture is that when companies have competition, then they can establish any kind of performance target they want, whether it’s faster revenue growth or better profitability, and then architect themselves so they can achieve their goals. Then, we can monitor that.

We do have evidence in repeated case studies of companies that set goals, defined an architecture, started to build the capabilities associated with that architecture, and did indeed improve their performance. We have wonderful case study results that should be very reaffirming. I accept that they are not conclusive.

Architectural maturity

We also have statistical support in some of the work we’ve done that shows that high performers in our sample of 102 companies, in fact, had greater architecture maturity. They had deployed a number of practices associated with good architecture.

Gardner: Is there something that’s new about this, rather than just trying to reengineer something?

Ross: Yes, the thing we’re learning about enterprise architecture is that there’s a cultural shift that takes place in an organization, when it commits to doing business in a new way, and that cultural shift starts with abandoning a culture of heroes and accepting a culture of discipline.

Nobody wants to get rid of the heroes in their company. Heroes are people who see a problem and solve it. But we do want to get past heroes sub-optimizing. What companies traditionally did before they started thinking about what architecture would mean, is they relied on individuals to do what seemed best and that clearly can sub-optimize in an environment that increasingly is global and requires things like a single face to the customer.

We also have statistical support in some of the work we’ve done that shows that high performers in our sample of 102 companies, in fact, had greater architecture maturity. They had deployed a number of practices associated with good architecture.

Gardner: Is there something that’s new about this, rather than just trying to reengineer something?

Ross: Yes, the thing we’re learning about enterprise architecture is that there’s a cultural shift that takes place in an organization, when it commits to doing business in a new way, and that cultural shift starts with abandoning a culture of heroes and accepting a culture of discipline.

Nobody wants to get rid of the heroes in their company. Heroes are people who see a problem and solve it. But we do want to get past heroes sub-optimizing. What companies traditionally did before they started thinking about what architecture would mean, is they relied on individuals to do what seemed best and that clearly can sub-optimize in an environment that increasingly is global and requires things like a single face to the customer.

We really just need architecture to pull out unnecessary cost and to enable desirable reusability. And the architect is typically going to be the person representing that enterprise view and helping everyone understand the benefits of understanding that enterprise view, so that everybody who can easily or more easily see the local view is constantly working with architects to balance those two requirements.

Gardner: Is this a particularly good time, from your vantage point, to undertake enterprise architecture?

Ross: It’s a great time for most companies. There will be exceptions that I’ll talk about in a minute. One thing we learned early on in the research is that companies who were best at adopting architecture and implementing it effectively had cost pressures. What happens when you have cost pressures is that you’re forced to make tough decisions.

If you have all the money in the world, you’re not forced to make tough decisions. Architecture is all about making tough decisions, understanding your tradeoffs, and recognizing that you’re going to get some things that you want and you are going to sacrifice others.

If you don’t see that, if you just say, “We’re going to solve that by spending more money,” it becomes nearly impossible to become architected. This is why investment banks are invariably very badly architected, and most people in investment banks are very aware of that. It’s just very hard to do anything other than say, “If that’s important to us, let’s spend more money and let’s get it.” One thing you can’t get by spending more money is discipline, and architecture is very tightly related to discipline.

Tough decisions

In a tough economy, when competition is increasingly global and marketplaces are shifting, this ability to make tough decisions is going to be essential. Opportunities to save costs are going to be really valued, and architecture invariably helps companies save money. The ability to reuse, and thus rapidly seize the next related business opportunity, is also going to be highly valued.

The thing you have to be careful of is that if you see your markets disappearing, if your product is outdated, or your whole industry is being redefined, as we have seen in things like media, you have to be ready to innovate. Architecture can restrict your innovative gene, by saying, “Wait, wait, wait. We want to slow down. We want to do things on our platform.” That can be very dangerous, if you are really facing disruptive technology or market changes.

So you always have to have that eye out there that says, “When is what we built that’s stable actually constraining us too much? When is it preventing important innovation?” For a lot of architects, that’s going to be tough, because you start to love the architecture, the standards, and the discipline. You love what you’ve created, but if it isn’t right for the market you’re facing, you have to be ready to let it go and go seize the next opportunity.

Gardner: Perhaps this environment is the best of all worlds, because we have that discipline on the costs which forces hard decisions, as you say. We also have a lot of these innovative IT trends that would almost force you to look at doing things differently. I’m thinking again of cloud, mobile, the big data issues, and even social-media types of effects.

Ross: Absolutely. We should all look at it that way and say, “What a wonderful world we live in.” One of the companies that I find quite remarkable in their ability to, on the one hand, embrace discipline and architecture, and on the other hand, constantly innovate, is USAA. I’m sure I’ll talk about them a little bit at the conference.

This is a company that just totally understands the importance of discipline around customer service. They’re off the charts in their customer satisfaction.

They’re a financial services institution. Most financial services institutions just drool over USAA’s customer satisfaction ratings, but they’ve done this by combining this idea of discipline around the customer. We have a single customer file. We have an enterprise view of that customer. We constantly standardize those practices and processes that will ensure that we understand the customer and we deliver the products and services they need. They have enormous discipline around these things.

Simultaneously, they have people working constantly around innovation. They were the first company to see the need for this deposit with your iPhone. Take a picture of your check and it’s automatically deposited into your account. They were nearly a year ahead of the next company that came up with that service.

The way they see it is that for any new technology that comes out, our customer will want to use it. We’ve got to be there the day after the technology comes out. They obviously haven’t been able to achieve that, but that’s their goal. If they can make deals with R&D companies that are coming up with new technologies, they’re going to make them, so that they can be ready with their product when the thing actually becomes commercial.

So it’s certainly possible for a company to be both innovative and responsive to what’s going on in the technology world and disciplined and cost effective around customer service, order-to-cash, and those other underlying critical requirements in your organization. But it’s not easy, and that’s why USAA is quite remarkable. They’ve pulled it off and they are a lesson for many other companies.

Gardner: Is The Open Group a good forum for your message and your research, and if so, why?

Ross: The Open Group is great for me, because there is so much serious thinking in The Open Group about what architecture is, how it adds value, and how we do it well. For me to touch base with people in The Open Group is really valuable, and for me to touch base to share my research and hear the push back, the debate, or the value add is perfect, because these are people who are living it every day.

Major themes

Gardner: Are there any other major themes that you’ll be discussing at the conference coming up that you might want to share with us?

Ross: One thing we have observed in our cases that is more and more important to architects is that the companies are struggling more than we realized with using their platforms well.

I’m not sure that architects or people in IT always see this. You build something that’s phenomenally good and appropriate for the business and then you just assume, that if you give them a little training, they’ll use it well.

That’s actually been a remarkable struggle for organizations. One of our research projects right now is called “Working Smarter on Your Digitized Platform.” When we go out, we find there aren’t very many companies that have come anywhere close to leveraging their platforms the way they might have imagined and certainly the way an architect would have imagined.

It’s harder than we thought. It requires persistent coaching. It’s not about training, but persistent coaching. It requires enormous clarity of what the organization is trying to do, and organizations change fast. Clarity is a lot harder to achieve than we think it ought to be.

The message for architects would be: here you are trying to get really good at being a great architect. To add value to your organization, you actually have to understand one more thing: how effectively are people in your company adopting the capabilities and leveraging them effectively? At some point, the value add of the architecture is diminished by the fact that people don’t get it. They don’t understand what they should be able to do.

We’re going to see architects spending a little more time understanding what their leadership is capable of and what capabilities they’ll be able to leverage in the organization, as opposed to which on a rational basis seem like a really good idea.

Getting started

Gardner: When you’re an organization and you’ve decided that you do want to transform and take advantage of unique opportunities for either technical disruption or market discipline, how do you go about getting more structure, more of an architecture?

Ross: That’s idiosyncratic to some extent, because in your dream world, what happens is that the CEO announces, “This is what we are going to be five years from now. This is how we are going to operate and I expect everyone to get on board.” The vision is clear and the commitment is clear. Then the architects can just say, and most architects are totally capable of this, “Oh, well then, here are the capabilities we need to build. Let’s just go build them and then we’ll live happily ever after.”

The problem is that’s rarely the way you get to start. Invariably, the CEO is looking at the need for some acquisitions, some new markets, and all kinds of pressures. The last thing you’re getting is some clarity around the vision of an operating model that would define your critical architectural capabilities.

What ends up happening instead is architects recognize key business leaders who understand the need for, reused standardization, process discipline, whatever it is, and they’re very pragmatic about it. They say, “What do you need here to develop an enterprise view of the customer, or what’s limiting your ability to move into the next market?”

And they have to pragmatically develop what the organization can use, as opposed to defining the organizational vision and then the big picture view of the enterprise architecture.

So in practice, it’s a much more pragmatic process than what we would imagine when we, for example, write books on how to do enterprise architecture. The best architects are listening very hard to who is asking for what kind of capability. When they see real demand and real leadership around certain enterprise capabilities, they focus their attention on addressing those, in the context of what they realize will be a bigger picture over time.

They can already see the unfolding bigger picture, but there’s no management commitment yet. So they stick to the capabilities that they are confident the organization will use. That’s the way they get the momentum to build. That is more art than science and it really distinguishes the most successful architects.

************

If you are interested in attending The Open Group’s upcoming conference, please register here: http://www3.opengroup.org/event/open-group-conference-san-francisco/registration

Dana Gardner is president and principal analyst at Interarbor Solutions, an enterprise IT analysis, market research, and consulting firm. Gardner, a leading identifier of software and cloud productivity trends and new IT business growth opportunities, honed his skills and refined his insights as an industry analyst, pundit, and news editor covering the emerging software development and enterprise infrastructure arenas for the last 18 years.

2 Comments

Filed under Enterprise Architecture, Enterprise Transformation, Semantic Interoperability

SF Conference to Explore Architecture Trends

By The Open Group Conference Team

In addition to exploring the theme of “Enterprise Transformation,” speakers at The Open Group San Francisco conference in January will explore a number of other trends related to enterprise architecture and the profession, including trends in service oriented architectures and business architecture. 

The debate about the role of EA in the development of high-level business strategy is a long running one. EA clearly contributes to business strategy, but does it formulate, plan or execute on business strategy?  If the scope of EA is limited to EA alone, it could have a diminutive role in business strategy and Enterprise Transformation going forward.

EA professionals will have the opportunity to discuss and debate these questions and hear from peers about their practical experiences, including the following tracks:

  • Establishing Value Driven EA as the Enterprise Embarks on Transformation (EA & Enterprise Transformation Track)  - Madhav Naidu, Lead Enterprise Architedt, Ciena Corp., US; and Mark Temple, Chief Architect, Ciena Corp.
  • Building an Enterprise Architecture Practice Foundation for Enterprise Transformation Execution  (EA & Business Innovation Track) – Frank Chen, Senior Manager & Principal Enterprise Architect, Cognizant, US
  • Death of IT: Rise of the Machines (Business Innovation & Technological Disruption: The Challenges to EA Track) –  Mans Bhuller, Senior Director, Oracle Corporation, US
  • Business Architecture Profession and Case Studies  (Business Architecture Track) – Mieke Mahakena, Capgemini,; and Peter Haviland, Chief Architect/Head of Business Architecture, Ernst & Young
  • Constructing the Architecture of an Agile Enterprise Using the MSBI Method (Agile Enterprise Architecture Track) – Nick Malike, Senior Principal Enterprise Architect, Microsoft Corporation, US
  • There’s a SEA Change in Your Future: How Sustainable EA Enables Business Success in Times of Disruptive Change (Sustainable EA Track)  – Leo Laverdure & Alex Conn, Managing Partners, SBSA Partners LLC, US
  • The Realization of SOA’s Using the SOA Reference Architecture  (Tutorials) – Nikhil Kumar, President, Applied Technology Solutions, US
  • SOA Governance: Thinking Beyond Services (SOA Track) – Jed Maczuba, Senior Manager, Accenture, US

In addition, a number of conference tracks will explore issues and trends related to the enterprise architecture profession and role of enterprise architects within organizations.  Tracks addressing professional concerns include:

  • EA: Professionalization or Marketing Needed? (Professional Development Track)  - Peter Kuppen, Senior Manager, Deloitte Consulting, BV, Netherlands
  • Implementing Capabilities With an Architecture Practice (Setting up a Successful EA Practice Track)  – Mike Jacobs, Director and Principal Architect, OmptumInsight; and Joseph May, Director, Architecture Center of Excellence, OmptumInsight
  • Gaining and Retaining Stakeholder Buy-In: The Key to a Successful EA Practice Practice (Setting up a Successful EA Practice Track)   – Russ Gibfried, Enterprise Architect, CareFusion Corporation, US
  • The Virtual Enterprise Architecture Team (Nature & Role of the Enterprise Architecture) – Nicholas Hill, Principal Enterprise Architect, Consulting Services, FSI, Infosys; and Musharal Mughal, Director of EA, Manulife Financials, Canada

 Our Tutorials track will also provide practical guidance for attendees interested in learning more about how to implement architectures within organizations.  Topics will include tutorials on subjects such as TOGAF®, Archimate®, Service Oriented Architectures,  and architecture methods and techniques.

For more information on EA conference tracks, please visit the conference program on our website.

Comments Off

Filed under Cloud/SOA, Enterprise Architecture, Enterprise Transformation, Semantic Interoperability, Service Oriented Architecture

2012 Open Group Predictions, Vol. 2

By The Open Group

Continuing on the theme of predictions, here are a few more, which focus on enterprise architecture, business architecture, general IT and Open Group events in 2012.

Enterprise Architecture – The Industry

By Leonard Fehskens, VP of Skills and Capabilities

Looking back at 2011 and looking forward to 2012, I see growing stress within the EA community as both the demands being placed on it and the diversity of opinions within it increase. While this stress is not likely to fracture the community, it is going to make it much more difficult for both enterprise architects and the communities they serve to make sense of EA in general, and its value proposition in particular.

As I predicted around this time last year, the conventional wisdom about EA continues to spin its wheels.  At the same time, there has been a bit more progress at the leading edge than I had expected or hoped for. The net effect is that the gap between the conventional wisdom and the leading edge has widened. I expect this to continue through the next year as progress at the leading edge is something like the snowball rolling downhill, and newcomers to the discipline will pronounce that it’s obvious the Earth is both flat and the center of the universe.

What I had not expected is the vigor with which the loosely defined concept of business architecture has been adopted as the answer to the vexing challenge of “business/IT alignment.” The big idea seems to be that the enterprise comprises “the business” and IT, and enterprise architecture comprises business architecture and IT architecture. We already know how to do the IT part, so if we can just figure out the business part, we’ll finally have EA down to a science. What’s troubling is how much of the EA community does not see this as an inherently IT-centric perspective that will not win over the “business community.” The key to a truly enterprise-centric concept of EA lies inside that black box labeled “the business” – a black box that accounts for 95% or more of the enterprise.

As if to compensate for this entrenched IT-centric perspective, the EA community has lately adopted the mantra of “enterprise transformation”, a dangerous strategy that risks promising even more when far too many EA efforts have been unable to deliver on the promises they have already made.

At the same time, there is a growing interest in professionalizing the discipline, exemplified by the membership of the Association of Enterprise Architects (AEA) passing 20,000, TOGAF® 9 certifications passing 10,000, and the formation of the Federation of Enterprise Architecture Professional Organizations (FEAPO). The challenge that we face in 2012 and beyond is bringing order to the increasing chaos that characterizes the EA space. The biggest question looming seems to be whether this should be driven by IT. If so, will we be honest about this IT focus and will the potential for EA to become a truly enterprise-wide capability be realized?

Enterprise Architecture – The Profession

By Steve Nunn, COO of The Open Group and CEO of the Association of Enterprise Architects

It’s an exciting time for enterprise architecture, both as an industry and as a profession. There are an abundance of trends in EA, but I wanted to focus on three that have emerged and will continue to evolve in 2012 and beyond.

  • A Defined Career Path for Enterprise Architects: Today, there is no clear career path for the enterprise architect. I’ve heard this from college students, IT and business professionals and current EAs. Up until now, the skills necessary to succeed and the roles within an organization that an EA can and should fill have not been defined. It’s imperative that we determine the skill sets EAs need and the path for EAs to acquire these skills in a linear progression throughout their career. Expect this topic to become top priority in 2012.
  • Continued EA Certification Adoption: Certification will continue to grow as EAs seek ways to differentiate themselves within the industry and to employers. Certifications and memberships through professional bodies such as the Association of Enterprise Architects will offer value to members and employers alike by identifying competent and capable architects. This growth will also be supported by EA certification adoption in emerging markets like India and China, as those countries continue to explore ways to build value and quality for current and perspective clients, and to establish more international credibility.
  • Greater Involvement from the Business: As IT investments become business driven, business executives controlling corporate strategy will need to become more involved in EA and eventually drive the process. Business executive involvement will be especially helpful when outsourcing IT processes, such as Cloud Computing. Expect to see greater interest from executives and business schools that will implement coursework and training to reflect this shift, as well as increased discussion on the value of business architecture.

Business Architecture – Part 2

By Kevin Daley, IBM and Vice-Chair of The Open Group Business Forum

Several key technologies have reached a tipping point in 2011 that will move them out of the investigation and validation by enterprise architects and into the domain of strategy and realization for business architects. Five areas where business architects will be called upon for participation and effort in 2012 are related to:

  • Cloud: This increasingly adopted and disruptive technology will help increase the speed of development and change. The business architect will be called upon to ensure the strategic relevancy of transformation in a repeatable fashion as cycle times and rollouts happen faster.
  • Social Networking / Mobile Computing: Prevalent consumer usage, global user adoption and improvements in hardware and security make this a trend that cannot be ignored. The business architect will help develop new strategies as organizations strive for new markets and broader demographic reach.
  • Internet of Things: This concept from 2000 is reaching critical mass as more and more devices become communicative. The business architect will be called on to facilitate the conversation and design efforts between operational efforts and technologies managing the flood of new and usable information.
  • Big Data and Business Intelligence: Massive amounts of previously untapped data are being exposed, analyzed and made insightful and useful. The business architect will be utilized to help contain the complexity of business possibilities while identifying tactical areas where the new insights can be integrated into existing technologies to optimize automation and business process domains.
  • ERP Resurgence and Smarter Software: Software purchasing looks to continue its 2011 trend towards broader, more intuitive and feature-rich software and applications.  The business architect will be called upon to identify and help drive getting the maximum amount of operational value and output from these platforms to both preserve and extend organizational differentiation.

The State of IT

By Dave Lounsbury, CTO

What will have a profound effect on the IT industry throughout 2012 are the twin horses of mobility and consumerization, both of which are galloping at full tilt within the IT industry right now. Key to these trends are the increased use of personal devices, as well as favorite consumer Cloud services and social networks, which drive a rapidly growing comfort among end users with both data and computational power being everywhere. This comfort brings a level of expectations to end users who will increasingly want to control how they access and use their data, and with what devices. The expectation of control and access will be increasingly brought from home to the workplace.

This has profound implications for core IT organizations. There will be less reliance on core IT services, and with that an increased expectation of “I’ll buy the services, you show me know to knit them in” as the prevalent user approach to IT – thus requiring increased attention to use of standards conformance. IT departments will change from being the only service providers within organizations to being a guiding force when it comes to core business processes, with IT budgets being impacted. I see a rapid tipping point in this direction in 2012.

What does this mean for corporate data? The matters of scale that have been a part of IT—the overarching need for good architecture, security, standards and governance—will now apply to a wide range of users and their devices and services. Security issues will loom larger. Data, apps and hardware are coming from everywhere, and companies will need to develop criteria for knowing whether systems are robust, secure and trustworthy. Governments worldwide will take a close look at this in 2012, but industry must take the lead to keep up with the pace of technology evolution, such as The Open Group and its members have done with the OTTF standard.

Open Group Events in 2012

By Patty Donovan, VP of Membership and Events

In 2012, we will continue to connect with members globally through all mediums available to us – our quarterly conferences, virtual and regional events and social media. Through coordination with our local partners in Brazil, China, France, Japan, South Africa, Sweden, Turkey and the United Arab Emirates, we’ve been able to increase our global footprint and connect members and non-members who may not have been able to attend the quarterly conferences with the issues facing today’s IT professionals. These events in conjunction with our efforts in social media has led to a rise in member participation and helped further develop The Open Group community, and we hope to have continued growth in the coming year and beyond.

We’re always open to new suggestions, so if you have a creative idea on how to connect members, please let me know! Also, please be sure to attend the upcoming Open Group Conference in San Francisco, which is taking place on January 30 through February 3. The conference will address enterprise transformation as well as other key issues in 2012 and beyond.

9 Comments

Filed under Business Architecture, Cloud, Cloud/SOA, Data management, Enterprise Architecture, Semantic Interoperability, Standards

Save the Date—The Open Group Conference San Francisco!

By Patty Donovan, The Open Group

It’s that time again to start thinking ahead to The Open Group’s first conference of 2012 to be held in San Francisco, January 30 – February 3, 2012. Not only do we have a great venue for the event, the Intercontinental Mark Hopkins (home of the famous “Top of the Mark” sky lounge—with amazing views of all of San Francisco!), but we have stellar line up for our winter conference centered on the theme of Enterprise Transformation.

Enterprise Transformation is a theme that is increasingly being used by organizations of all types to represent the change processes they implement in response to internal and external business drivers. Enterprise Architecture (EA) can be a means to Enterprise Transformation, but most enterprises today because EA is still largely limited to the IT department and transformation must go beyond the IT department to be successful. The San Francisco conference will focus on the role that both IT and EA can play within the Enterprise Transformation process, including the following:

  • The differences between EA and Enterprise Transformation and how they relate  to one another
  • The use of EA to facilitate Enterprise Transformation
  • How EA can be used to create a foundation for Enterprise Transformation that the Board and business-line managers can understand and use to their advantage
  • How EA facilitates transformation within IT, and how does such transformation support the transformation of the enterprise as a whole
  • How EA can help the enterprise successfully adapt to “disruptive technologies” such as Cloud Computing and ubiquitous mobile access

In addition, we will be featuring a line-up of keynotes by some of the top industry leaders to discuss Enterprise Transformation, as well as themes around our regular tracks of Enterprise Architecture and Professional Certification, Cloud Computing and Cybersecurity. Keynoting at the conference will be:

  • Joseph Menn, author and cybersecurity correspondent for the Financial Times (Keynote: What You’re Up Against: Mobsters, Nation-States and Blurry Lines)
  • Celso Guiotoko, Corporate Vice President and CIO, Nissan Motor Co., Ltd. (Keynote: How Enterprise Architecture is helping NISSAN IT Transformation)
  • Jeanne W. Ross, Director & Principal Research Scientist, MIT Center for Information Systems Research (Keynote: The Enterprise Architect: Architecting Business Success)
  • Lauren C. States, Vice President & Chief Technology Officer, Cloud Computing and Growth Initiatives, IBM Corp. (Keynote: Making Business Drive IT Transformation Through Enterprise Architecture)
  • Andy Mulholland, Chief Global Technical Officer, Capgemini (Keynote: The Transformed Enterprise)
  • William Rouse, Executive Director, Tennenbaum Institute at Georgia Institute of Technology (Keynote: Enterprise Transformation: An Architecture-Based Approach)

For more on the conference tracks or to register, please visit our conference registration page. And stay tuned throughout the next month for more sneak peeks leading up to The Open Group Conference San Francisco!

1 Comment

Filed under Cloud, Cloud/SOA, Cybersecurity, Data management, Enterprise Architecture, Semantic Interoperability, Standards

2012 Open Group Predictions, Vol. 1

By The Open Group

Foreword

By Allen Brown, CEO

2011 was a big year for The Open Group, thanks to the efforts of our members and our staff – you all deserve a very big thank you. There have been so many big achievements, that to list them all here would mean we would never get to our predictions. Significantly though, The Open Group continues to grow and this year the number of enterprise members passed the 400 mark which means that around 30,000 people are involved, some more so than others, from all over the world.

Making predictions is always risky but we thought it might be fun anyway. Here are three trends that will wield great influence on IT in 2012 and beyond:

  • This year we experienced the consumerization of IT accelerating the pace of change for the enterprise at an astonishing rate as business users embraced new technologies that transformed their organizations. As this trend continues in 2012, the enterprise architect will play a critical role in supporting this change and enabling the business to realize their goals.
  • Enterprise architecture will continue its maturity in becoming a recognized profession. As the profession matures, employers of enterprise architects and other IT professionals, for that matter, will increasingly look for industry recognized certifications.
  • As globalization continues, security and compliance will be increasing issues for companies delivering products or services and there will be a growing spotlight on what might be inside IT products. Vendors will be expected to warrant that the products they purchase and integrate into their own products come from a trusted source and that their own processes can be trusted in order not to introduce potential threats to their customers. At the same time, customers will be increasingly sensitive to the security and dependability of their IT assets. To address this situation, security will continue to be designed in from the outset and be tightly coupled with enterprise architecture.

In addition to my predictions, Other Open Group staff members also wanted to share their predictions for 2012 with you:

Security

By Jim Hietala, VP of Security

Cloud security in 2012 becomes all about point solutions to address specific security pain points. Customers are realizing that to achieve an acceptable level of security, whether for IaaS, SaaS, or PaaS, they need to apply controls in addition to the native platform controls from the Cloud service provider. In 2012, this will manifest as early Cloud security technologies target specific and narrow security functionality gaps. Specific areas where we see this playing out include data encryption, data loss prevention, identity and access management, and others.

Cloud

By Chris Harding, Director of Interoperability

There is a major trend towards shared computing resources that are “on the Cloud” – accessed by increasingly powerful and mobile personal computing devices but decoupled from the users.

This may bring some much-needed economic growth in 2012, but history shows that real growth can only come from markets based on standards. Cloud portability and interoperability standards will enable development of re-usable components as commodity items, but the need for them is not yet appreciated. And, even if the vendors wanted these standards for Cloud Computing, they do not yet have the experience to create good ones.  But, by the end of the year, we should understand Cloud Computing better and will perhaps have made a start on the standardization that will lead to growth in the years ahead.

Here are some more Cloud predictions from my colleagues in The Open Group Cloud Work Group: http://blog.opengroup.org/2011/12/19/cloud-computing-predictions-for-2012/

Business Architecture

By Steve Philp, Professional Certification

There are a number of areas for 2012 where Business Architects will be called upon to engage in transforming the business and applying technologies such as Cloud Computing, social networking and big data. Therefore, the need to have competent Business Architects is greater than ever. This year organizations have been recruiting and developing Business Architects and the profession as a whole is now starting to take shape. But how do you establish who is a practicing Business Architect?

In response to requests from our membership, next year The Open Group will incorporate a Business Architecture stream into The Open Group Certified Architect (Open CA) program. There has already been significant interest in this stream from both organizations and practitioners alike. This is because Open CA is a skills and experience based program that recognizes, at different levels, those individuals who are performing in a Business Architecture role. I believe this initiative will further help to develop the profession over the next few years and especially in 2012.

1 Comment

Filed under Business Architecture, Cloud, Cybersecurity, Enterprise Architecture, Enterprise Transformation, Semantic Interoperability, Uncategorized

Why do pencils have erasers?

By Andrew Josey and Garry Doherty, The Open Group

We know that TOGAF® isn’t perfect. In fact, it probably never will be, but sometimes, especially after a major release, it’s a good idea to stop and look backwards after its been in implementation for a while… just to make sure we’ve gotten it right and to review the standard for reasons of further clarification and to improve consistency.

That’s why we’re releasing TOGAF® 9.1. It contains a set of corrections to address comments raised since the introduction of TOGAF® 9 in 2009. We have been able to address over 400 of the comments received against TOGAF® 9, resulting in over 450 changes to the standard.

The maintenance updates in TOGAF® 9.1 are based on feedback received on the framework as organizations have put it to good use over the past three years. As such the changes are upwards compatible adding clarification, consistency and additional detail where needed. Some of the most significant updates include:

  • The SOA chapter (Part III, Chapter 22, Using TOGAF to Define & Govern SOAs) has been updated to include the latest Open Group SOA Work Group output providing guidance on adapting the ADM phases for SOA
  • ADM Phases E and F (Part II, Chapters 13 and 14) have been reworked to match the level of detail in other phases, and the uses of terminology for Transition Architecture, Roadmap, and Implementation Strategy clarified and made consistent
  • Corrections have been applied to aspects of the Content Metamodel (Part IV, Chapter 34, The Content Metamodel) including the metamodel diagrams
  • The concepts of levels, iterations and partitions have been clarified and made consistent. This includes a reorganization of material in Part III, Chapter 19, Applying Iteration to the ADM and Chapter 20, Applying the ADM across the Architecture Landscape, and also Part V, Chapter 40, Architecture Partitioning
  • The terms “artifact” versus “viewpoint” have been clarified and made consistent. This includes a restructuring of Part IV, Chapter 35, Architectural Artifacts
  • Changes have been made to improve general usability including:
    • The artifacts for each phase are now listed in the phase descriptions
    • Duplicate text in several places has been replaced with an appropriate reference
    • The “Objectives” sections of the phases have been reworked
    • Some artifacts have been renamed to better reflect their usage

If you’re already TOGAF® 9 certified,  don’t worry about the status of your certification. The TOGAF® 9 Certification for People Program has been designed to accommodate maintenance updates to the TOGAF® 9 standard such as TOGAF® 9.1. So impacts on the program are minimal:

  • The two levels of certification remain as TOGAF® 9 Foundation and TOGAF® 9 Certified.
  • Individuals who are currently certified in the TOGAF® 9 People Certification program remain certified.

TOGAF 9.1 is available for online reading at http://www.opengroup.org/togaf/ and available in The Open Group Bookstore at http://www.opengroup.org/bookstore/catalog/g116.htm .

A detailed description of the changes between TOGAF 9 and TOGAF 9.1 is available at http://www.opengroup.org/bookstore/catalog/u112.htm .

So now you know why pencils have erasers… because perfection is a constantly moving target!

5 Comments

Filed under Enterprise Architecture, Standards, TOGAF, TOGAF®

What does developing an IT Strategy mean?

By Serge Thorn, Architecting the Enterprise

I have observed many situations where a c-level person was supposed to document an IT Strategy in a short period of time, in order to prepare the following year’s annual budget. Very often, they lack much supporting documented business information in order to achieve this task. The result is a weak strategy, sometimes ignored by the user’s community, the key stakeholders.

A weak IT strategy can be costly and wasteful, especially for resource-constrained organizations that operate with minimal budget, tools, knowledge and people.  It also implies that organizations cannot respond to changing business requirements rapidly enough. The absence of strategic anticipation causes organizations to be inefficiently reactive, forcing them to work in a constant state of catch-up.

An IT Strategy should answer the following questions:

  • Are we doing the right things with technology to address the organization’s most important business priorities and continuously deliver value to the clients?
  • Are we making the right technology investments?
  • Do we measure what is the real value to the organization derived from that technology?
  • Is our current Information Technology agile enough; flexible to continuously support a successful organization?
  • Is our Information Technology environment properly managed, maintained, secured, able to support the clients, and is it cost effective?
  • Can our strategy support current and future business needs?

Quite often the first thing we should consider when writing such a document is the targeted audience and its content. Different people with varying roles and responsibilites may read an IT Strategy within a company, so the document may need to serve several different purposes.  It is not easy to pitch a strategy to different levels in the hierarchy within an organization, and at the appropriate level of detail. Sometimes it is too detailed and does not always match the stakeholder’s needs.

An IT Strategy is an iterative process to align IT capabilities with the business strategy and requirements:

  • It is a documented and approved process (part of the organization’s governance framework)
  • It is iterative (it needs to be frequently be revisited). Traditionally, IT strategies are updated and communicated on an annual basis, usually to meet budget cycles. This should be considered the minimum review period. If an emerging technology surfaces that has the potential to enhance the business, it should be investigated and communicated to the business as soon as possible. A one-year cycle may  be too late.
  • It  is a strong alignment of business and IT capabilities rather than designing IT solutions to support business requirements
    • Assuming  that both business and IT capabilities drive each other
    • Assuming that business drives IT and not the other way around
  • The IT Strategy sets future direction for IT function in the organization
    • Ensuring that the IT budget is spent on value creation activities for the business
    • Creating shareholder value
    • Helping to maximize the return on IT investments
  • The IT Strategy may include sub-elements such as:
    • Infrastructure strategy
    • Application strategy
    • Integration strategy
    • Service strategy
    • Sourcing strategy
    • Innovation strategy

This pyramid diagram can be used to illustrate the IT strategy and vision, and how the technology and business strategies are totally aligned. At the top of the pyramid is the enterprise overarching vision. Aligned below that is how IT supports the vision by becoming a premier IT organization in creating competitive advantage for the clients. The IT vision is in turn supported by three pillars: integration, improvement, and innovation.

To deliver this, the business strategy should clearly be articulated and documented taking into account some IT aspects. There are different ways of gathering these business inputs.

The first approach is a very classical one where you develop a questionnaire in business terms which asks each business unit to identify their future requirements for infrastructure growth, taking into account capacity and availability requirements. This extracts the data you need for business driven strategy.

This questionnaire may include some of the following examples of questions:

  1. What are your top 5 business “pain” points? These are things that you wish you had a solution for
  2. What are your top 5 business objectives? These can be short term or long term, can be driven by revenue, cost, time, time to market, competitive advantage, risk or various other reasons
  3. How do you plan to achieve these objectives?
  4. What will we gain by leveraging IT Capabilities across the business?
  5. What is in the way of achieving your business imperatives?
  6. Can IT help achieve your business imperatives?
  7. How much do you spend on IT capabilities?
  8. What is your technology ROI?
  9. Does your company have a plan for technology?
  10. Does your business plan include a technology plan?
  11. Where is IT being used across your business unit?

The second approach would be the use of Enterprise Architecture that I will explain later on.

With this input you may now start to consider the structure of your document. It may look similar to this example below:

An executive summary

  • An introduction
    • The purpose
    • The background
    • The Business drivers
    • The Organizational drivers
    • The IT drivers
  • The Business and IT aspects
    • The Business Goals and Objectives
    • The IT approaches and principles
  • The IT components
    • Business application systems
    • IT infrastructure
    • Security and IT Service continuity
  • Structure, organization and management
    • IT Governance
    • Skills, knowledge and education
    • IT Financial management
    • KPIS, measurement and metrics, balance scorecards
  • Technologies opportunities
  • Key issues

And this is where Enterprise Architecture may have to play an important and even crucial role. Some companies I have encountered have an Enterprise Architecture team, and in parallel, somebody called an IT Strategist. Frequently the connection is non-existing or quite weak.  Other organizations may also have a Strategic Planning unit, again without any connection with the Enterprise Architecture team.

An Enterprise Architecture must play the important role of assessing; existing IT assets, architecture standards and the desired business strategy to create a unified enterprise-wide environment – where the core hardware and software systems are standardised and integrated across the entire organisation’s business processes, to greatly enhance competitive advantage and innovation. The IT Strategy details the technologies, application and the data foundation needed to deliver the goals of the corporate strategy, while Enterprise Architecture is the bridge between strategy and execution; providing the organising logic to ensure the integration and standardisation of key processes that drive greater agility, higher profitability, faster time to market, lower IT costs, improved access to shared customer data and lower risk of mission-critical systems failures.

As a real example, TOGAF 9 is perfect way to produce that IT Strategy document during the Phase F: Migration Planning.

Below you will find the relationship between some phases of the ADM and the structure of the above document. It needs to be said that we should probably use a Strategic architecture level to deliver a first version of the document, which then could be reviewed with Segment or Capability architectures.

Content Examples Enterprise Architecture and TOGAF
An executive summary
An introduction (This document must be business oriented)
Content Examples Enterprise Architecture and TOGAF
The purpose Key elements of the scope, audience, time horizon The Preliminary phase is about defining ‘‘where, what, why, who, and how” Enterprise Architecture will be done and will provide all information. It also creates the conditions and context for an Architecture Capability
The background Business problems, constraints (financial, resources, IT, legal, etc.) This is covered by the Phase A: Architecture Vision. An Architecture Visionsets stage for each iteration of ADM cycle.-Provides high-level, aspirational view of target the sponsor uses to describe how business goals are met and stakeholder concerns are addressed
-Provides an executive summary version of full Architecture
-Drives consensus on desired outcomeThe Business Scenarios is used to discover and document business requirements, identify constraints, etc.
The Business drivers Market conditions, competition, consumer trends, new customers, products sales, costs savings, incremental services revenues, drivers related to the IT function In the Phase A: Architecture Vision, we:Identify business goals and strategic drivers-Ensure that descriptions used are current-Clarify any areas of ambiguityDefine constraints-Enterprise-wide constraints

-Architecture project-specific constraints

The Organizational drivers Profitability, financial performance, change in strategic objectives, end of the product development life cycle, mergers and acquisitions, staffs, risks
The IT drivers New or obsolete technologies, updates Considering that IT is part of the Business, these drivers should also be considered in that phase
The Business and IT aspects
The Business Goals and Objectives Market growth, entering new markets, addressing manufacturing capacities In the Phase A: Architecture Vision, we:Identify business goals and strategic drivers
-Ensure that descriptions used are current
-Clarify any areas of ambiguity
-Define constraints
-Enterprise-wide constraints
-Architecture project-specific constraints
The IT approaches and principles IT standards, development, implementation, delivery, testing, consolidation, maturity, best practices Standards should be documented in the SIB (Standard Information Base)When we define the Architecture Governance Framework during the Preliminary Phase, we identy the various touch points with existing other frameworks in the organization
IT principles should have already have been defined by the IT department
The IT components
Business application systems Baseline (main applications: ERP, CRM, customers facing systems). Future plans, concerns, time period, priorities) This will be addressed by Phase C: Information Systems based on the Statement of Architecture Work, output from the Phase A
IT infrastructure Baseline (servers, network , middleware, technical services) This will be addressed by Phase D: Technology Architecture based on the Statement of Architecture Work, output from the Phase A
Security and IT Service continuity Issues, challenges, opportunities related to security, security principles, controls Security concerns are addressed during all phases of the ADM
Structure, organization and management
IT Governance Best practices, frameworks, management and monitoring, resource management, portfolio management, vendors management, IT service management, project management, etc. IT Governance will be considered when the Architecture Governance Framework is defined. There will obviously be touch points between the ADM and some other best practices used by the organization. IT Governance is defined outside of the Enterprise Architecture programme
Skills, knowledge and education Skills, knowledge and education Enterprise Architecture skills will have to be addressed by the Architecture Capability Framework. Other skills may also be identified independently of the Enterprise Architecture programme
IT Financial management IT budget, costs structures, measurement and metrics, targets, areas needing investments, etc. This is addressed is outside of the Enterprise Architecture programme
KPIS, measurement and metrics, balance scorecards IT performance measurements on SMART objectives ((Specific, Measurable, Achievable, Realistic, & Time bound) Every governance frameworks may have its own KPIs. Enterprise Architecture KPIs may be added to that list.
Technologies opportunities Emerging technologies, business related benefits This can be done in parallel of the Enterprise Architecture programme
Key issues and initiatives Summary or link to the IT Project portfolio This can be done in parallel of the Enterprise Architecture programme
Color legend
Direct relationship with Enterprise Architecture
Indirect relationship with Enterprise Architecture
Produced somewhere else

The next step would be the review of the IT Strategy document by the main stakeholders who would accept or reject technology opportunities. This could also be used as an important source of information for the Strategic Planning exercise (please refer to another article for additional information:  “How Strategic Planning relates to Enterprise Architecture?“).

Once the IT Strategy has been reviewed, amended and authorised (which should in reality already be approved, as it is the result of various ADM cycles and the output of Phase F: Migration planning), the multi-disciplinary programme team for the implementation during Phase G: Implementation Governance, will deliver the solutions to the business.

As already mentioned previously, the outline strategies will be refined and expanded with a low level of detail when addressing Segment and Capability architectures. This is the part that meets the first challenge described above, where we need different levels of detail for different stakeholders. The documents should be hierarchical, with the ability to drill down to lower levels as more detail is required.

One of the main reasons for developing an Enterprise Architecture with TOGAF 9 is to support the business by providing the fundamental technology and process structure for an IT Strategy.  Enterprise Architecture is the superset that represents both Business and IT Strategy; this is reflected in Enterprise Architecture’s basic structure of strategy, business architecture and technology/information architecture. One can certainly do an IT Strategy without Enterprise Architecture, but Enterprise Architecture cannot be done without an IT Strategy; the same would apply to business strategy/business architecture.

Serge Thorn is CIO of Architecting the Enterprise.  He has worked in the IT Industry for over 25 years, in a variety of roles, which include; Development and Systems Design, Project Management, Business Analysis, IT Operations, IT Management, IT Strategy, Research and Innovation, IT Governance, Architecture and Service Management (ITIL). He has more than 20 years of experience in Banking and Finance and 5 years of experience in the Pharmaceuticals industry. Among various roles, he has been responsible for the Architecture team in an international bank, where he gained wide experience in the deployment and management of information systems in Private Banking, Wealth Management, and also in IT architecture domains such as the Internet, dealing rooms, inter-banking networks, and Middle and Back-office. He then took charge of IT Research and Innovation (a function which consisted of motivating, encouraging creativity, and innovation in the IT Units), with a mission to help to deploy a TOGAF based Enterprise Architecture, taking into account the company IT Governance Framework. He also chaired the Enterprise Architecture Governance worldwide program, integrating the IT Innovation initiative in order to identify new business capabilities that were creating and sustaining competitive advantage for his organization. Serge has been a regular speaker at various conferences, including those by The Open Group. His topics have included, “IT Service Management and Enterprise Architecture”, “IT Governance”, “SOA and Service Management”, and “Innovation”. Serge has also written several articles and whitepapers for different magazines (Pharma Asia, Open Source Magazine). He is the Chairman of the itSMF (IT Service Management forum) Swiss chapter and is based in Geneva, Switzerland.

3 Comments

Filed under Enterprise Architecture, Semantic Interoperability, TOGAF®

Taking Decisions In The Face Of Uncertainty (Responsible Moments)

By Stuart Boardman, KPN

Ruth Malan recently tweeted a link to a piece by Alistair Cockburn about the Last Responsible Moment concept (LRM) in Lean Software Development. I’ve been out of software development for a while now but I could guess what that might mean in an “agile” context and wondered how it might apply to problems I’ve been considering recently in Enterprise Architecture. Anyway, Alistair Cockburn is an interesting writer who would be deservedly famous even if he’d never done anything after writing the most practical and insightful book ever written about use cases. So I read on. The basic idea of the LRM is that in order to deal with uncertainty you avoid taking deterministic decisions until just before it would become irresponsible (for cost or delivery reasons) not to take them. Or to put it another way, don’t take decisions you don’t yet need to take if the result will be to constrain your options but do be ready to take them when it’s dangerous to wait longer.

Alistair’s not a big fan of LRM. He makes the following statement: “If you keep all decisions open until the hypothetical LRM, then your brain will be completely cluttered with open decisions and you won’t be able to keep track of them all.” Later in the discussion, he modifies this a bit but it certainly struck a chord with me. I’ve argued recently in this column that the degree of uncertainty (I called this entropy) in which enterprise architects have to operate is only increasing and that this in turn is due to three factors: the increasing rate of change happening in or affecting the enterprise; the increasing complexity of the environment in which the enterprise exists; and the decreasing extent to which any one enterprise can control that environment. This in turn increases the level of complexity in decision making. I’ll come back to these factors later but if you give me the benefit of the doubt for the moment, you can see that there’s actually a pretty good argument for taking any decision you can reasonably take (i.e. one which does not unjustifiably constrain everything else), as early as you can – in order to minimize complexity as you go along.

This is not (repeat not) a dogma. If it’s totally unclear what decision you should take, you’d probably be better off waiting for more information – and a last responsible moment will undoubtedly arrive.

So assuming you gave me the benefit of the doubt, you might now reasonably be thinking that this is theoretically all very well but how can we actually put it into practice. To do that we need first to look at the three sources of complexity I mentioned:

  • That the rate of change is increasing is pretty much a truism. Some change is due to market forces such as competition, availability/desirability of new capabilities, withdrawal of existing capabilities or changes in the business models of partners and suppliers. Some change is due to regulation (or deregulation) or to indirect factors such as changing demographics. Factors such as social media and Cloud are perhaps more optional but are certainly disruptive – and themselves constantly in change.
  • The increase in complexity of the environment is largely due to the increase in the number of partners and to more or less formal value networks (extended enterprise), to an increased number of delivery channels and to lack of standardization at both the supply and delivery ends.
  • The decrease in control (or more accurately in exclusive and total control) arises from all forms of shared services, which the enterprise one way or another makes use of. This can be Cloud (in which case we talk about multi-tenancy), social media (in which case we talk about anarchy) but equally well the extended enterprise network where not merely do our partners and suppliers have other customers but they also have their own partners and suppliers who have other customers. A consequence of most of this is that you can’t expect to be consulted before change decisions are made.

At best you will be notified well enough in advance of it happening. So you need to take that into account in what you implement.

Each of these factors may affect what the organization is – its core values, its key value propositions, its strategy. They may also affect how it carries out its business – its key activities and processes, its partners and even its customers. And they can affect how those activities and processes are implemented, which by the way can in turn drive change at the strategic level – it’s not just one way traffic – but this is a subject worthy of its own blog.

The point is that, if we want to be able to deal with this, to make sensible decisions in a non-deterministic environment, we would do well to address them where they first manifest themselves in order to avoid a geometric expansion of complexity further on. I’m inclined to think this is primarily in the business architecture (assuming we all accept that business architecture is not just a collection of process models). Almost all of the factors are encountered first here and subsequently reflected possibly in strategy and nearly always on the implementation side. If we make the reasonable assumption that the implementation side will encounter its own complexities, we can at least keep that manageable by not passing on all the possible options from the business architecture.

I said almost all factors are encountered first in the business architecture. The most obvious exceptions I can think of are the Infrastructure as a Service and Platform as a Service variants on Cloud. There’s a good case to be made that the effects of these are primarily felt within IT (strategy and implementation). But wherever we start, the principle doesn’t change – start the analysis at the first point of impact.

The next thing we need to do is look for ways to a) reduce the level of entropy in the part of the system we start with and b) understand how to make decisions that don’t create unnecessary lock in.  There’s not enough space in a blog to go into this in detail but it’s worth mentioning some new and some established techniques.

My attention has recently been drawn (by Verna Allee and others) to the study of networks of things, organizations and people. This in turn makes a lot of use of visualizations. These enable us to “see” the level of entropy around the particular element we’re focusing on – without the penalty of losing sight of the big picture. An example that I found useful is by Eric Berlow.  Another concept in this area involves identifying what are referred to as communities (because the idea came out of the study of social networks – clusters of related elements, which are only loosely coupled to other communities. These techniques allow us to reduce the scope (and therefore complexity) of the problem we’re trying to solve at any one time without falling into the trap of assuming it’s entirely self- contained.

A few blogs ago I mentioned an idea of Robert Phipps’s, where he visualizes the various forces within an organization as vectors. Each vector represents some factor driving (or even constraining) change. Those can be formal or informal organizational groupings (people), stakeholders both within and external to the organization, economic factors around supply or revenue, changes in the business model or even in technology. In that blog I used this as a way of illustrating entropy but Robert is actually looking at ways of applying measures to these vectors in order to be able to establish their actual force (and direction) and therefore their impact on change. Turning an apparently random factor into something knowable reduces the level of entropy and makes us more confident about taking decisions early – and therefore in turn reduces the entropy at a later stage.

One more example: Ruth Malan and Dana Bredemeyer produced a paper last year in which they examined the idea that organizations can make the most use of the creativity of their personnel by replacing the traditional hierarchical and compartmentalized structures with what they called a fractal approach. The idea is that patterns of strategy creation are reflected in all parts of an organization, thus making strategy integral to an organization rather than merely dictated from “above”. It has the added benefit of making the overall complexity more manageable. Architects belong in each fractal both as creators and interpreters of strategy. I can’t possibly do this long paper justice here but I wanted to mention an additional thought I had. What can also help architects is to look for these fractals even in formally hierarchical organizations. There’s a great chance that they really exist and are just waiting for someone to pay them attention.

Having achieved focus on a manageable area and gathered as much meaningful data as possible, we can then apply some basic (but often forgotten or ignored) design principles. Think of separation of concerns, low coupling, high cohesion. All that starts by focusing on the core purpose of the element(s) of the architecture we’ve zoomed in on. And folks, the good news is that this will all have to wait for another occasion.

The very last thing I want to say is something I tend to hammer on about. You have to take some risks. No creative, successful organization does not take risks. You need a degree of confidence about the level and potential impact of the risk but at the end of the day you’ll have to make a decision anyway. Even if you believe that everything is potentially knowable, you know that we often don’t have the information available to achieve that. So you take a gamble on something that seems to deliver value and where the risk is at worst manageable. And by doing that you reduce the total entropy in the system and make taking other decisions easier.

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. 

1 Comment

Filed under Business Architecture, Cloud/SOA, Enterprise Architecture

Enterprise Architecture and Emergence of Social Media

By Raghuraman Krishnamurthy, Cognizant Technology Solutions

If your enterprise is predominantly a consumer goods enterprise, you would have noticed tectonic shifts in the marketing focus. Traditionally, the goods and services were promoted through the enterprise websites and advertisements; however today the added focus is on having a vibrant social media presence. Success stories of Intuit and McDonald add credence to this trend. Stories like how customer complaints that are tweeted gain immediate attention abound in the world of consumer goods. Digital media has enabled conversations and enterprises are eager at the possibility of hearing directly from the customers. The new mantras are: more listening than talking, formation of communities, word of mouth as the ultimate marketing vehicle, active monitoring of social media, identification of key advocates, etc. Internally, within enterprises, Yammer is a very popular tool for tweeting. That information systems that acquired distinct organizational flavor are now making ground for customer/human flavor is no more a fiction.

This trend of social media brings in challenges and opportunities to EA. EA aims to holistically understand business; recent attempts on extended enterprises tended to predominantly focus on “firms part of the value chain” of enterprise. Social media is a new plane of reality where customers influence the enterprise success in the marketplace. The notion of extended enterprises now need to embrace social presence. Any EA effort that does not take cognizance of emerging forces will invite greater risk in building overall understanding of enterprise and its operating environment.  Earlier CRM efforts were focused on understanding individual customers; the need of the today is to understand the communities.

Like how The Open Group suggested changes to TOGAF to accommodate SOA, we need to work on integrating social media. Some suggested approaches for EA are:

Business Architecture:

  • Focus on forming & cultivating community, nurturing and ensuring vibrancy
  • Promote word of mouth and induce consumers to share experiences
  • Listen to social media

Information Architecture:

  • Integrate information from social media to internal systems
  • Develop analytical capabilities towards measuring effective presence in the social world

Opportunities & Solutions:

  • Build vs Buy – subscription models to get feeds

How are you addressing the social media channel in your enterprise? Would love to hear your experiences.

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.

1 Comment

Filed under Business Architecture, Enterprise Architecture

Does IT mean Information Technology? Or is it Just a Department?

By Stuart Boardman, KPN

Some Enterprise Architects I greatly respect frequently stress the point that EA is not just or even primarily about IT. Some others go as far as to argue that it’s nothing to do with IT at all (the same people appear to think that this applies to all technology). At the other extreme, people, possibly unaware of these discussions, appear to believe that it’s only about IT. The problem with both extremes is that, when it comes down to it they are talking about the role of an organization’s own IT department rather than the role of information technology in business. The result is that IT is perceived as purely a support function (i.e. nothing more than the automation of traditional business activities). That works well for both parties, because it’s then easy to isolate it and make it either a universe in itself or an uninteresting minor galaxy.

Continue reading

Comments Off

Filed under Enterprise Architecture

Today’s projects, tomorrow’s bigger picture: an examination of Enterprise Transformation

By Allen Brown, CEO, The Open Group

Enterprise Transformation seems to be gathering momentum within the Enterprise Architecture community. It’s a term that seems to have originated in the EA community but which could be quite strange to senior executives or others in non-IT functions. Although Google finds 39 million web search results for the term, almost all of them reflect an IT perspective. The Journal of Enterprise Transformation is an official journal of the Institute of Industrial Engineers (IIE) and the International Council on Systems Engineering (INCOSE). While the systems engineering community’s notion of systems is based on general systems theory and is thus inclusive of much more than IT systems, the EA community has a tendency to see the world though “IT-colored glasses;” and this in turn colors its understanding of Enterprise Transformation.

Continue reading

1 Comment

Filed under Enterprise Architecture, Enterprise Transformation

A momentous first year for The Open Group EMMMv™ Forum

By Sarina Viljoen, The Open Group South Africa

It’s been nearly a year since The Open Group published its first set of best practices for the natural resources industry, the Exploration and Mining Business Reference Model (EM Model). The EM Model, which was developed under the auspices of The Open Group Exploration, Mining, Metals and Minerals Vertical (EMMMv™) Forum and The Open Group South Africa, establishes a blueprint for organizations in the natural resources industry to help implement Enterprise Architectures within their organizations and provide standard operating best practices and support for vendors delivering technical and business solutions to the industry. Designed to cater to business activities across a variety of different types of mining organizations, the model is helping companies align both their business and technical procedures to provide better measures for shared services, health, safety and environmental processes.

Continue reading

Comments Off

Filed under EMMMv™, Enterprise Architecture

How EA is leading enterprise transformation in France

By Eric Boulay, The Open Group France

Earlier this week, in Paris, The Open Group France held the latest in a series of one-day conferences focused on Enterprise Architecture. As usual, the event delivered high-value content in the form of an excellent keynote presentation and case studies. These covered the retail, gambling, and financial industries — including two from CIOs of major French corporations: Continue reading

2 Comments

Filed under Enterprise Architecture, TOGAF®

Finding the value in SOA

by Stephen Bennett, Oracle

Republished with permission from CIO Update from an article published on behalf of The Open Group.

Confronted with the age old problems of agility and complexity, today’s CIOs are under more pressure than ever to improve the strategic value of IT to the business. At best, these challenges have increased costs, limited innovation and increased risk. At worst, they have reduced IT’s ability to respond to changing business needs in a timely fashion.

Yet, changes for business and IT are continuing to occur at an ever-increasing pace. To keep up, enterprises need to adopt an agile, flexible architecture style with a proven strategic approach to delivering IT to the business.

Over the last year, I have seen a resurgence of CIOs using Enterprise Architecture (EA) as a key tool to address these challenges. In the past, EA has experienced difficulties within the enterprise. It has been unfairly seen as primarily a documentation exercise and, when applied incorrectly, EA can — ironically — become a silo in of itself. To make sure that EA has better success this time, CIOs must make their EA efforts more actionable.

Step back: SOA

Service oriented architecture (SOA) has been positioned as an architectural style specifically intended to reduce costs, increase agility and, most importantly, simplify the business and the interoperation of different parts of that business.

A key principle of SOA is the structuring of business capabilities into meaningful, granular services as opposed to opaque and siloed business functions. This makes it possible to quickly identify and reuse any existing realized functional capabilities, thus avoiding the duplication of similar capabilities across the organization. By standardizing the behavior and interoperation of these services, it’s possible to limit the impacts of change and to forecast the likely chain of impacts.

Despite its popularity, relatively few enterprises have been able to measure and demonstrate the value of SOA. This is due primarily to the approach that enterprises have taken when adopting and applying SOA. In most cases, enterprises interpret SOA as simply another solution development approach. As a result, SOA has been relegated or wrongly positioned as a purely integration technology, rather than the strategic enabler that it can be.

Because of this, SOA must not be seen as a solution development approach that starts and ends once a solution is delivered. It must be seen as an on-going process that, when coupled with a strategic framework, can change and evolve with the business over time. Unfortunately, many enterprises adopt SOA without utilizing a strategic framework, causing a host of challenges for their business.

Just a few of the challenges I have seen include:

  • More complexity and moving parts
  • Increased costs
  • Projects taking longer than before
  • Solutions more fragile than ever
  • Little or no agility
  • Difficulty identifying and discovering services
  • Exponentially growing governance challenges
  • Limited service re-use
  • Duplication of effort leading to service sprawl
  • Multiple siloed technology focused SOAs
  • Funding for service oriented projects being cut

It’s no wonder that SOA has a bad reputation.

To address these challenges, enterprises utilizing or considering adopting SOA must align it with an EA framework that elevates the importance of the needs of the enterprise rather than only considering the requirements of individual projects.

Step forward: TOGAF® 9

Now used by 80 percent of the Fortune Global 50, TOGAF® , an Open Group standard, is an architecture framework that contains a detailed method and set of supporting resources for developing an EA. As a comprehensive, open method for EA, TOGAF 9 complements and can be used in conjunction with other frameworks that are more focused on specific aspects of architecture, such as MDA and ITIL.

The Open Group’s new guide, Using TOGAF to Define and Govern Service-Oriented Architectures, aims to facilitate common understanding of the development of SOA while offering a phased approach to maximizing its business impact based on the popular TOGAF methodology. Let’s take a look at the main takeaways from the guide:

Organization readiness - An enterprise first needs to adopt the principle of service-orientation. However, successful SOA depends on the readiness of the enterprise to become service-oriented. To get started with SOA, the guide recommends conducting a maturity assessment. Such an assessment is available from The Open Group and enables a practitioner to assess an organization’s SOA maturity level and define a roadmap for incremental adoption to maximize business benefits at each stage along the way.

Scope - The size and complexity of an enterprise affects the way its architecture develops. Where there are many different organizational and business models, it is not practical to integrate them within a single architecture. It is therefore generally not appropriate to develop a single, integrated SOA for a large and complex enterprise.

TOGAF defines enterprise as any collection of organizations that has a common set of goals. For example, an enterprise could be a government agency, a whole corporation, a division of a corporation, a single department, or a chain of geographically distant organizations linked together by common ownership.

The guide highlights an approach for enterprise architects to identify the business areas where SOA will be of greatest benefit and make a significant impact so that they can be prioritized. This approach will help organizations avoid using SOA with the wrong situations to maximize their investment and overall business impact.

Communication, communication, communication - Aspects of TOGAF 9 were extended and enhanced to cover specific service-oriented concepts and terminology such as service contracts. Service contracts formalize the functional and non-functional characteristics of a business service and how it interacts with other business services. This enables a business vocabulary to be derived that allows IT to converse with the business in terms of business process and business services and abstracting away the complexity of the underlying technical services.

Governance - The identification of service and service portfolios is a key task for SOA. The questions of what service and service portfolios the enterprise will have, and how they will be managed must be taken with an enterprise level view.

Just because you have identified a number of services does not automatically mean they will add value to the enterprise and that they should be realized (at least not initially). Governance plays a key role here and the guide recommends the establishment of a SOA governance and creating a linkage to both IT and EA governance in the enterprise.

The Open Group has a wealth of information available in this area, specifically an SOA governance framework that provides context and definitions that enable organizations to understand, customize, and deploy SOA governance.

The relationship between EA and SOA is a powerful and synergistic one. They are key enablers for one another, making EA actionable while making the wider business benefits of SOA obtainable.

SOA is certainly not the only architectural approach that your enterprise will require. But it can smooth the alignment and adoption of other architecture styles (e.g., business process management, event-driven architecture) into an EA framework. So rather than reinvent the wheel, organizations should consider using a well-established framework such as TOGAF to elevate and extend the value of SOA.

The Open Group’s new guide is a must-read for any enterprise architect currently using TOGAF, but remember that it needs to be customized and extended to your enterprises unique situation. Now, if only The Open Group had a guide on using TOGAF to define and govern Cloud Computing!

Stephen Bennett is a senior enterprise architect at Oracle, an author, and a 25-year technologist focused on providing thought leadership, best practices, and architecture guidance around SOA and Cloud Computing. He has co-chaired a number of Work Groups within The Open Group around SOA Governance and TOGAF/SOA.

Comments Off

Filed under Service Oriented Architecture