How to Mind Map: A Beginner’s Guide

image

I am a huge Mind Mapping fan. I have mind map software on most of my devices. When I saw that Peter Bakker @pbmobi tweeted this I had to share.

 

Mind mapping is a bit of a change in the way we think about how we describe our ideas. The IQ Matrix resource below has some really helpful resources to get you started:

http://blog.iqmatrix.com/mind-map/how-to-mind-map-a-beginners-guide

Advertisements

Enterprise Architecture, The Great Journey from IT to the Business

image

There is a ton of buzz happening in the Enterprise Architecture community regarding the panel discussion Examining the Current State of EA 2011  at the Open Group Conference. This has been reported on by the majority of the EA and Technology bloggers such as Joe McKendrick  though his post “Do enterprise architects work for IT or the business or what?” and the Charles Babcock post on “Enterprise Architects’ Role In Aligning IT With Business”.

 

The buzz is centered around the notion of EA moving to the business. I am really happy to see the industry lock in on this. With the confusion over the past couple years on if Enterprise Architecture would survive the economic climate, we found out it thrived. To do that it needed to reduce the waste.

 

To some, this analysis is less of an revelation but more of validation. This is certainly a validation of all those hard years of work towards a business driven Enterprise Architecture.

 

Enterprise Architecture has gone on a bit of a Lewis and Clark adventure over the past 20ish years. From it’s beginnings as a classification and decision making framework to where it is now has been a dramatic transformation. 

 

image

 

It is interesting to hear the dramatic statements of “Enterprise Architecture In The Year 2020: Strategic Nexus or Oblivion?” when most of us practitioners have been betting our careers on this transformation to occur. From the brief look at the history and roadmap above it looks like a very likely possibility.

 

When we look at the road ahead what are the key inhibitors to this transformation:

  •  Accountability in the Business – Until EA moves from the advisor to owning a portion of the responsibility and accountabilities within the business it will struggle to make that move. From the perspective of an executive in the business, why would they trust an EA if he/she doesn’t have any “skin in the game”? Forrester Research VP Gene Leganza discussed a similar aspect in the statement “"owns the business planning process”
  • Maturity – This one word says it all. The EA space has to mature before the business can double down on it. This is everything from the approaches, what EA focuses on, the methods used, approaches, outcomes, competencies and standardization. Industry standards bodies are a great place to start. We seen the transformation of TOGAF from TOGAF 7 the IT Edition to TOGAF 8 Enterprise Edition. I think that TOGAF 10 has to be Business Edition. TOGAF 9 has started this with the focus more on business architecture.
  • Competencies – The journey from an IT focused architecture group to business driven Enterprise Architecture group naturally there is a built up infrastructure to support these companies through the transition. For there to be a transformation the competencies of Enterprise Architects need to be revisited and calibrated to a new set of standards. Organizations like IASA with their CITA-P and the Open Group with ITAC certifications focus on the Enterprise Architect part of the equation. They need to up-level their certifications to make the business a first class citizen.
  • Business Conversations – Dropping the tech talk and speaking in terms of the business will go a long way. Instead of complex IT speak about the benefits of virtualization or cloud shift to discuss how you can lower the cost per transaction or how to enable a remote sales for to increase customer satisfaction. Current EA’s have learned their business but some struggle to talk in terms of the business.
  • Discover and Deliver the Value – With so many failures in delivery of solutions for the business, EA’s need to get back to the roots of what is value and how to maximize it for their business.  This point is driven home from the latest analyst thinking from the Standish Group stating that 50% of all technology initiatives are a waste of money. If EA’s are going to be credible with and in the business they are the best equipped to turn this around.

 

While these macro level inhibitors are substantial, there have been great strides in the industry to tackle them. There is investment in EA despite the challenges. We are seeing evidence that companies like Caterpillar, Aetna and United Airlines elevating EA to new heights.

 

Let’s keep making the great strides as an EA industry and profession!

 

Technorati Tags:

Navigating through the Complexities of Architectures

image

A common challenge among architects and architecture organizations is the challenge of properly understanding the landscape of architecture assets within and external to the enterprise. With all the different definitions, hierarchy and levels of abstraction it can be difficult to really get your arms this problem space.

At an architecture summit were questions like:

  • What is a pattern?
  • Is there a difference between a reference architecture and a pattern?
  • How would you classify an architecture asset?
  • What is the difference or the line between architecture and implementation?

These are all great questions and I am sure there are questions asked by many others as well.

image

There are things you can do to alleviate this pain. Below are four activities I have used to help clear up the confusion:

  • Lock on Vocabulary – A large part of the problem (not the only) is one of vocabulary. Having a common definition for these terms goes a long way. After walking through the questions above with architects what we quickly found was that we were actually deriving to the same definition but using different terms.
  • Classification – As you go through the terms there will be quite a bit of iteration on the relationships of these terms. This classification or taxonomy is important to lock for your organization. It helps you understand the context and the relationships of the asset to all other things. 
  • Leverage Mainstream Vocabulary and Classification – In a past experience of mine (7 or so years back) when aiding in building an Office of Enterprise Architecture we found this same issue of locking on terms we can all understand as an enterprise. We spent the better part of 6 months (in duration not effort) just trying to lock on terms. This involved passionate debates and religious wars on how people understood the space and their personal preferences. Save yourself the heartache and leverage an existing standard. It will be better for your organization in the long run.
  • Provide Examples – Run through a few scenarios to exercises the vocabulary and classification system. This will accelerate the end users understanding of the concepts.

 

There has actually been quite a bit of work done in this space. The Open Group’s TOGAF 9 has defined this space really well at the macro level. This is what they call the Enterprise Continuum. There site has a lot of detail on this and you can find more on the Enterprise Continuum Online Book Chapter

The definition of the Enterprise Continuum is: a view of the Architecture Repository that provides methods for classifying architecture and solution artifacts as they evolve from generic Foundation Architectures to Organization-Specific Architectures

So essentially it is providing a classification and common set of definitions for the space. There is a small bit of taxonomy work here but it is inferred not in a typical taxonomy format but the outcomes are that of a taxonomy.

image

 

I really like that this framework accommodates real world challenges such as regulatory compliance, business change, technology disruptors and competitive forces. This is all rationalized in the context of business and IT strategy which is a first class citizen in the framework.

This is demonstrated in the diagram below when you look at the traceability aspects of the framework.

image

Above shows abstraction at a high-level and below is an exercised high-level architecture partitioning of the model that can be mapped to the ADM methodology. This is what makes the model actionable as it leverages the deep definition of an architecture method to make the classification implementable.

 

image

If you are looking to supplement TOGAF or look at other perspectives there are great resources at the OMG, IEEE, FODA, and others. Of all the sources TOGAF (in my opinion) is by far the most complete across the spectrum and is the highest used by both enterprises and tools vendors.

Another helpful piece of context setting which isn’t necessarily in the Enterprise Continuum is the notion of an Architectural Style. I talk about his in a post I wrote a couple years back in “What is an Architectural Style” . I think that this is complementary to the Enterprise Continuum as it is more of guiding principles of the Architecture and Solution Continuum.

I define an architecture style as:

An Architecture Style is a logical grouping of patterns or architecture references that is implemented through cohesive methods for solving a problem area with a unique set of concerns.

 

At the time this was a way to reduce confusion around key macro technology patterns such as SOA, now this has shifted to another amorphous concept of Cloud Computing. See below for an example:

Mike Walker's Blog: Architecture Styles Example

 

Additionally, J.D. Meier has a good post on Reference Models, Reference Architectures and Reference
Implementations
that could be either worked into the TOGAF vocabulary but also used independently if need be.  The reason I bring this post up is that he has some good definitions that could be an alternative or provide additional context.

See J.D.’s descriptions below:

  • Reference Model – A Reference model is a model of something that embodies the basic goals or ideas, and you can use it at as a reference for various purposes. It’s like holding up a diamond and looking at the different facets. It basically serves as a backdrop or canvas, or a foundation and springboard for deeper dives. They are also useful for pulling together a bird’s-eye view of a domain or problem space. A well-known example is the OSI model. Key Attributes include: abstract, entities and Relationships, technology agnostic, and they clarify things within a context. By using a model, you can focus on higher-level concepts, ideas, and decisions.
  • Reference Architecture – A reference architecture provides a proven template solution for an architecture for a particular domain. It’s the high-level “blue prints” for putting the pieces of the puzzle together.
  • Reference Implementation – A reference Implementation goes beyond a reference architecture and is an actual implementation. This is where the rubber meets the road and it serves as an exemplar down at the implementation level.

 

Communication is Key for Enterprise Architects

image

Combined with reading some of the latest news in EA and having spent a full week with many architects at an internal Microsoft event called TechReady, I decided to share a seemly relevant topic of concern for architects, communication. I’m pulling areas of a deck from a recent speaking engagement in which I talk about the future of the role of an architect.

At the event I talked to an infrastructure architect that has aspirations of becoming an enterprise architect. He mentioned a few successes and a few trials. The problem was he seemed to be stuck in a rut in the organization. He felt he wasn’t as relevant as he could be. And he was right. He was an extremely intelligent and competent architect, I could see that within a five minute conversation.

There was a problem though. The communication he felt most comfortable with was that of talking about infrastructure. His conversations were grounded in that level of depth.

So why is that a problem? He’s a smart guy. He can solve lots of problems. Isn’t infrastructure everywhere? So why isn’t it a relevant topic or depth to speak at?

It’s story time!

So imagine you are in a big meeting with a variety of different stakeholders on the big cloud project. You have people from the marketing department, LOB stakeholders, business analysts and executive stakeholders. Let’s take a step back and look in the mirror to see what our customer could see and hear if architects communicate with such technical depth.

The questions from around the table: “Sure, if you say so…” , “What did he just say?”, “The what component?”, “I didn’t follow that”, “Where’s my next meeting?”

This has been an all too common behavior from architects. I have to admit, I have done it myself. It’s easy to do. But we need to be mindful of the messages we convey.

 

Now let’s turn the tables a bit. It can be frustrating for us architects as well. Have you ever been on a project where you in your most compelling voice tell a business person that there is impossibilities/contradictions in what they are asking or how much of a bad idea their technical request may be? I would venture to guess most of us have had those conversations at one point or another in our career.

So since we poked fun at ourselves, let’s look at how it can seem to architects on the other end of the table.

 

Sound and look familiar? It happens and sometimes it’s down right frustrating.

 

So what are the takeaways?

The key is to understand your audience. You can do that by understanding these four areas of communication:

  1. Awareness – Understand who they are, the role they play in the organization and any personal biases they may have. Once you do that, you can manage the conversation with a level of situational leadership.
  2. Context – Make sure your communication is at the right depth and coverage area for the audience. Missing this can really hurt your credibility and applicability in the organization. 
  3. Story – Take the customer on a journey by learning how to tell a compelling story for what your trying to accomplish. One of the most powerful tools you can use is your own experiences. Use real examples in your pitches to ground your audience.
  4. Empathy – Not only should you understand your audiences challenges but you should empathize with them as well. If you do this, you have skin in the game and are much more credible as you are truly partnering with your customer.

 

 

Technorati Tags: ,

Examining the Current State of EA 2011

Today the Open Group has released their yearly state of enterprise architecture on their blog (http://blog.opengroup.org/2011/02/16/podcast-examining-the-state-of-ea-and-findings-of-recent-survey ). The panel discussion led by Dana Gardner with Interabor Solutions was recorded at the Open Group conference last week in San Diego.

The panel discussed topics that are top of mind for enterprise architects and the InfoSys Enterprise Architecture Survey 2011.

For me there were some key quotes that we all should think about. See below:

image

 

Great conversation and I can’t say that I disagree with them. Some years I had questioned some of the analysis, but it’s seems pretty spot on this year.

After having experiences running a couple Enterprise Architecture organizations I can tell you that we are going through times of change. Big changes. These changes are redefining the role of an architect, which ever variety you are. They will all go through some form of transformation.

I like how Len Fehskens brought up the bit about how our profession is the new kid on the block. Architecture didn’t really go mainstream until 10 years ago. Before that I really didn’t see much in the title of an architect much less an enterprise architect. There are some parallels with other roles in IT. The role of the CTO was a political hot potato 15 to 20 years ago. Executives didn’t understand the value or the need for such a role. That role too went through a transformation and did indeed remain. The same is true with Enterprise Architecture.

 

Listen to this recorded podcast here:
http://opengroupblog.files.wordpress.com/2011/02/briefingsdirect-panel-of-architecture-experts-analyze-ea-survey-data.mp3 

 

Full transcript below:

BriefingsDirect-Panel of Architecture Experts Analyze EA Survey Data

The following is the transcript of a sponsored podcast panel discussion on the findings from a study on the current state and future direction of enterprise architecture from The Open Group Conference, San Diego 2011.

Dana Gardner: Hi, this is Dana Gardner, Principal Analyst at Interarbor Solutions, and you’re listening to BriefingsDirect.

Today, we present a sponsored podcast discussion in conjunction with The Open Group Conference, held in San Diego in the week of February 7, 2011. We’ve assembled a panel to examine the current state of enterprise architecture (EA) and analyze some new findings on this subject from a recently completed Infosys annual survey.

We’ll see how the architects themselves are defining the EA team concept, how enterprise architects are dealing with impact and engagement in their enterprises, and the latest definitions of EA deliverables and objectives. [Disclosure: The Open Group is a sponsor of BriefingsDirect podcasts.]

We’ll also look at where the latest trends around hot topics like cloud and mobile are pushing the enterprise architects towards a new future. Here with us to delve into the current state of EA and the survey results, is Len Fehskens, Vice President of Skills and Capabilities at The Open Group. Welcome, Len.

Len Fehskens: Thanks, Dana.

Gardner: Nick Hill, Principal Enterprise Architect at Infosys Technologies. Welcome.

Nick Hill: Thank you very much.

Gardner: Dave Hornford, Architecture Practice Principal at Integritas, as well as Chair of The Open Group’s Architecture Forum. Welcome, Dave.

Dave Hornford: Welcome. Thanks for being here.

Gardner: Chris Forde, Vice President of Enterprise Architecture and Membership Capabilities for The Open Group.

Chris Forde: Good morning.

Gardner: We have a large group here today. We’re also joined by Andrew Guitarte. He is the Enterprise Business Architect of Internet Services at Wells Fargo Bank. Welcome.

Andrew Guitarte: Thank you very much.

Gardner: And, Ahmed Fattah. He is the Executive IT Architect in the Financial Services Sector for IBM, Australia. Welcome.

Ahmed Fattah: Thank you, Dana.

Gardner: Nick Hill, let’s go to you first. You’ve conducted an annual survey. You just put together your latest results. You asked enterprise architects what’s going on in the business. What are the takeaways? What jumped out at you this year?

Hot topics

Hill: There are several major takeaways. There were some things that were different about this year’s survey. One, we introduced the notion of hot topics. So, we had some questions around cloud computing. And, we took a more forward-looking view in terms of not so much what has been transpiring with enterprise architectures since the last survey, but what are they looking to go forward to in terms of their endeavors. And, as we have been going through economic turmoil over the past 2-3 years, we asked some questions about that.

We did notice that in terms of the team makeup, a lot of the sort of the constituents of the EA group are pretty much still the same, hailing from largely the IT core enterprise group. We looked at the engagement and impacts that they have had on their organizations and, as well, whether they have been able to establish the value that we’ve noticed that enterprise architects have been trying to accomplish over the past 3-4 years.

This was our fifth annual survey, which was started by Sohel Aziz. We did try to do some comparative results from previous surveys and we found that some of things were the same, but there are some things that are shifting in terms of EA.

More and more, the business is taking hold of the value that enterprise architects bring to the table, enterprise architects have been able to survive the economic troubled times, and some companies have even increased their investment in EA. But, there was a wide range of topics, and I’m sure that we’ll get to more of those as this discussion goes on.

Gardner: One of the things that you looked at was the EA team. Are we defining who these people are differently? Has that been shifting over the past few years?

Hill: Essentially, no. If you took a look at this year’s survey compared to 2007-2008 surveys, largely they’ve come from core IT with some increase from the business side, business architects and some increase in project managers. The leader of the EA group is still reporting through the IT chain either to the CIO or the CTO.

Gardner: Dave Hornford.

Hornford: Are you seeing that the leader of the architecture team is an architect or manager? The reason I’m asking is that we’re seeing an increasing shift in our client base to not having an architect lead the architecture team?

Hill: Well, that was very interesting. We didn’t exactly point to that kind of a determination. We wanted to see who they actually reported into. That would help us get some indication of how well they would be able to sell their value within the enterprise, if you’re largely aligned more with the IT or more with the business side functions.

Gardner: Chris Forde, you’ve been observing a lot of these issues, is this a particularly dynamic time, or is this a time where things are settling out? Is there any way to characterize the way in which the enterprise architect occupation or professional definition is involved with the organization? Where are we on this?

Forde: Actually, I’ll defer commentary on the professional aspect of things to my colleague Len. In terms of the dynamics of EA, we’re constantly trying to justify why enterprise architects should exist in any organization. That’s actually no different than most other positions are being reviewed on an ongoing basis, because of what the value proposition is for the organization.

Certifying architects

What I’m seeing in Asia is that a number of academic organizations, universities, are looking for an opportunity to certify enterprise architects, and a number of organizations are initiating, still through the IT organization but at a very high CIO-, CTO-level, the value proposition of an architected approach to business problems.

What I’m seeing in Asia is an increasing recognition of the need for EA, but also a continuing question of, “If we’re going to do this, what’s the value proposition,” which I think is just a reasonable conversation to have on a day- to-day basis anyway.

Gardner: So, Chris is pointing to the fact that business transformation is an undercurrent to all these things in many different occupations, and processes and categories of workforce and even workflow are being reevaluated. Len, how is the EA job or function playing into that? Is this now an opportunity for it to start to become more of a business transformation occupation?

Fehskens: When you compare EA with all the other disciplines that make up a modern enterprise, it’s the new kid on the block. EA, as a discipline, is maybe 20 years old, depending on what you count as the formative event, whereas most of the other disciplines that are part of the modern enterprise at least hundreds of years old.

So, this is both a real challenge and a real opportunity. The other functions have a pretty good understanding of what their business case is They’ve been around for a long time, and the case that they can make is pretty familiar. Mostly they just have to argue in terms of more efficient or more effective delivery of their results.

For EA, the value proposition pretty much has to be reconstructed from whole cloth, because it didn’t really exist, and the value of the function is still not that well understood throughout most of the business.

So, this is an opportunity as well as a challenge, because it forces the maturing of the discipline, unlike some of these older disciplines who had decades to figure out what it was that we’re really doing. We have maybe a few years to figure out what it is we’re really doing and what we’re really contributing, and that helps a lot to accelerate the maturing of the discipline.

I don’t think we’re there completely yet, but I think EA, when it’s well done, people do see the value. When it’s not well done, it falls by the side of the road, which is to be expected. There’s going to be a lot of that, because of the relative use of the discipline, but we’ll get to the point where these other functions have and probably a lot faster than they did.

Gardner: So this is a work in progress, but that comes at a time when the organization is in transition. So, that might be a good match up. Nick, back to the survey. It seems, from my reading of it, that business strategy objectives are being given more to EA, perhaps because there is no one else in that über position to grab on to that and do something.

Hill: I think that’s very much the case. The caveat there is that it’s not necessarily an ownership. It’s a matter of participation and being able to weigh in on the business transformations that are happening and how EA can be instrumental in making those transformations successful.

Follow through

Now, given that, the idea is that it’s been more at a strategic level, and once that strategy is defined and you put that into play within an enterprise the idea is how does the enterprise architect really follow-through with that, if they are more focused on just the strategy not necessarily the implementation of that. That’s a big part of the challenge for enterprise architects — to understand how they percolate downwards the standards, the discipline of architecture that needs to be present within an organization to enable that strategy in transformation.

Gardner: Len.

Fehskens: One of the things that I am seeing is an idea taking hold within the architecture community that architecture is really about making the connection between strategy and execution.

If you look at the business literature, that problem is one that’s been around for a long time. A lot of organizations evolved really good strategies and then failed in the execution, with people banging their heads against the wall, trying to figure out, “We had such a great strategy. Why couldn’t we really implement it?”

I don’t know that anybody has actually done a study yet, but I would strongly suspect that, if they did, one of the things that they would discover was there wasn’t something that played the role of an architecture in making the connection between strategy and execution.

I see this is another great opportunity for architects, if we can express this idea in language that the business people understand, and strategy to execution is language that businesspeople understand, and we can show them how architecture facilitates that connection. There is a great opportunity for a win-win situation for both the business and the architecture community.

Gardner: Chris.

Forde: I just wanted to follow the two points that are right here, and say that the strategy to execution problem space is not at all peculiar to IT architects or enterprise architects. It’s a fundamental business problem. Companies that are good at translating that bridge are extremely effective and it’s the role of architects in that, that’s the important thing, we have to have the place at the table.

But, to imagine that the enterprise architects are solely responsible for driving execution of a strategy in an organization is a fallacy, in my opinion. The need is to ensure that the team of people that are engaged in setting the strategy and executing on it are compelling enough to drive that through the organization. That is a management and an executive problem, a middle management problem, and then driving down to the delivery side. It’s not peculiar to EA at all in my opinion.

Gardner: Andrew at Wells Fargo Bank, you wear a number of hats outside of your organization that I think cross some of these boundaries. The idea of the enterprise architect or a business architect, where do you see this development of the occupation going, the category going, and what about this division between strategy and execution?

Guitarte: I may not speak for the b
ank itself, but from my experience of talking with people from the grassroots to the executive level, I have seen one very common observation, enterprise architects are caught off-guard, and the reason there is that there is this new paradigm. In fact, there is a shift in paradigm that business architecture is the new EA, and I am going out beyond my peers here in terms of predicting the future.

Creating a handbook

That is going to be the future. I am the founding chairman of the Business Architecture Society. Today, I am an advisory member of the Business Architecture Guild. We’re writing, or even rewriting, the textbooks on EA. We’re creating a handbook for business architects. What my peers have mentioned is that they are bridging the strategy and tactical demands and are producing the value that business has been asking for.

Gardner: Okay, we also see from the survey that process flexibility, and standardization seems to be a big topic. Again, they’re looking to the architects in the organization to try to bridge that, to move above and beyond IT and applications into process, standardization, and automation across the organization.

Ahmed, where do you see that going, and how do you think the architect can play a role in furthering this goal of process flexibility and standardization?

Fattah: The way I see the market is consistent with the results of the survey in that they see the emergence of the enterprise architect as business architect to work on a much wider space and make you focus more on the business. There are a number of catalysts for that. One of them is a business process, the rise of the business process management, as a very important discipline within the organization.

That, in a way, had some roots from Six Sigma, which was really a purely business aspect, but also from service oriented architecture (SOA), which has itself now developed into business process, decomposition and implementation.

That gives very good ammunition and support for the strategic decomposition of the whole enterprise as components that, with business process, is actually connecting elements between this. The business process architect is participating as a business architect using this business process as a major aspect for enabling business transformation.

I’m very encouraged with this development of business architecture. By the way, another catalyst now is a cloud. The cloud will actually purify or modify EA, because all the technical details maybe actually outsourced to the cloud provider, where the essence of what IT will support in the organization becomes the business process.

On one hand, I’m encouraged with the result of the survey and what I’ve seen in the organization, but on the other hand, I am disappointed that EA hasn’t developed these economic and business bases yet. I agree with Len that 20 years is a short time. On the other hand, it’s a long time for not applying this discipline in a consistent way. We’ll get much more penetration, especially with large organization, commercial organization, and not the academic side.

Gardner: So, if we look at that potential drop between the strategy and the execution, someone dropping the ball in that transition, what Ahmed is saying that cloud computing could come in whereby your strategy could be defined, your processes could be engineered, and then the tactical implementation of those could be handed off to the cloud providers. Is that a possible scenario from where you sit, Dave?

Hornford: I think it’s a possible scenario. I think more driving from it is the ability to highlight the process or business service requirements and not tie them to legacy investments that are not decomposed into a cloud. Where you have a separation to a cloud, you’re required to have the ability to improve your execution. The barriers in execution in our current world are very closely tied to our legacy investments in software asset with physical asset which are very closely tied to our organizational structure.

Gardner: How about you, Chris Forde, do you see some goodness or risk in ameliorating the issue of handing off strategy to a cloud provider?

Abdicating responsibility

Forde: Any organization that hands over strategic planning or execution activity to a third-party is abdicating its own responsibility to shareholders, as they are a profit-making organizations. So I would not advocate that position at all.

Hornford: You can’t outsource thinking?

Forde: Well, you can, but then you give up control, and that’s not a good situation. You need to be in control of your own destiny. In terms of what Ahmed was talking about, you need to be very careful as you engage with the third-party that they are actually going to implement your strategic intent.

You need to have a really strong idea of what it is you want from the provider, articulating clearly, and set up a structure that allows you to manage and operate that with their strength in the game. If you just simply abdicate that responsibility and assume that that’s going to happen, it’s likely to fail.

Gardner: So there probably be clearly be instances where handing off responsibility at some level will make sense and won’t make sense, but who better than the enterprise architect to make that determination? Ahmed.

Fattah: I agree, on one hand, the organization shouldn’t abdicate the core function of the businesses in defining a strategy and then executing it right.

However, an example, which I’m seeing as a trend, but a very slow trend — outsourcing architecture itself to other organizations. We have one example in Australia of a very large organization, which gives IBM the project execution, the delivery organization. Part of that was architecture. I was part of this to define with the organization their enterprise architecture, the demarcation between what they outsource and what they retain.

Definitely, they have to retain certain important parts, which is strategy and high-level, but outsourcing is a catalyst to be able to define what’s the value of this architecture. So the number of architectures within our software organization was looked with a greater scrutiny. They are monitoring the value of this delivery, and value was demonstrated. So the team actually grew; not shrunk.

Forde: In terms of outsourcing knowledge skills and experience in an architecture, this is a wave of activity that’s going to be coming. My point wasn’t that it wasn’t a valid way to go, but you have to be very careful about how you approach it.

My experience out of the Indian subcontinent has been that having a bunch of people labeled as architects is different than having a bunch of people that have the knowledge, skills, and experience to deliver what is expected. But in that region, and in Asia and China in particular, what I’m seeing is a recognition that there is a market there. In North America and in Europe, there is a gap of people with these skills and experience. And folks who are entrepreneurial in their outlook in Asia are certainly looking to fill that gap.

So, Ahmed’s model is one that can work well, and will be a burgeoning model over the next few years. You’ve to build the skill base first.

Gardner: Thank you, Chris Forde. Andrew, you had something?

Why the shift?

Guitarte: There’s no disagreement about what’s happening today, but I think the most important questi
on is to ask why there is this shift. As Nick was saying, there is a shift of focus, and outsourcing is a symptom of that shift.

If you look back, Dave mentioned that in any organization there are two forces that tried to control the structure. One is the techno structure, which EA belongs to, and the main goal of a techno structure is to perpetrate themselves in power, to put it bluntly. Then, there is the other side, which is the shareholders, who want to maximize profit, and you’ve seen that cycle go back and forth.

Today, unfortunately, it’s the shareholders who are winning. Outsourcing for them is a way to manage cash flow, to control costs, and unfortunately, we’re getting hit.

Gardner: Nick, going back to the survey. When you asked about some of these hot trends — cloud, outsourcing, mobile, the impact — did anything jump out at you that might add more to our discussion around this shifting role and this demarcation between on-premises and outsource?

Hill: Absolutely. The whole concept of leveraging the external resources for computing capabilities is something we drove at. We did find the purpose behind that, and it largely plays into our conversation behind the impact of business. It’s more of a cost reduction play.

That’s what our survey respondents replied to and said the reason why the organization was interested in cloud was to reduce cost. It’s a very interesting concept, when you’re looking at why the business sees it as a cost play, as opposed to a revenue-generating, profit-making endeavor. It causes some need for balance there.

Gardner: So cutting cost, but at what price, Len?

Fehskens: The most interesting thing for me about cloud is that it replays a number of scenarios that we’ve seen happen over and over and over and over again. It’s almost always the case that the initial driver for the business to get interested in something is to reduce cost. But, eventually, you squeeze all the water out of that stone and you have to start looking at some other reason to keep moving in that direction, keep exploiting that opportunity.

That almost invariably is added value. What’s happening with cloud is that it’s forcing people to look at a lot of the issues that they started to address with SOA. But, the problem with SOA was that a lot of vendors managed to turn it into a technology issue. “Buy this product and you’ll have SOA,” which distracted people from thinking about the real issue here, which is figuring out what are the services that the business needs.

Once you understand what the services are that the business needs, then you can go and look for the lowest-cost provider out in the cloud to make that connection. But, once you’ve already made that disconnection between the services that the business needs and how they are provided, you can then start orchestrating the services on the business side from a strategically driven perspective to look at the opportunities to create added value.

You can assemble the implementation that delivers that added value from resources that are already out there that you don’t have to rely on your in-house organization to create it from scratch. So, there’s a huge opportunity here, but it’s accompanied by an enormous risk. If you get this right, you’re going to win big. But if you get it wrong, you are going to lose big.

Gardner: Ahmed, you had some thoughts?

Cloud has focus

Fattah: When we use the term, cloud, like many other terms, we refer to so many different things, and the cloud definitely has a focus. I agree that the focus now on reducing cost. However, when you look at the cloud as providing pure business service such as software as a service (SaaS), but also business process orchestrated services with perhaps outsourcing business process itself, it has a huge potential to create this mindset for organization about what they are doing and in which part they have to minimize cost. That’s where the service is a differentiator. They have to own it. They have to invest so much of it. And, they have to use the best around.

Definitely the cloud will play in different levels, but these levels where it will work in a business architecture is actually distilling the enterprise architecture into the essence of it, which is understanding what service do I need, how I sort the services, and how I integrate them together to achieve the value.

Gardner: So, the stakes are rather high. We have an opportunity where things could be very much more productive, and I’ll use that term rather than just cost savings, but we also have the

risk of some sort of disintermediation, dropping the ball, and handing off the strategic initiatives to the tactical implementation and/or losing control of your organization.

So, the question is, Dave Hornford, isn’t the enterprise architect in a catbird seat, in a real strong position to help determine the success or failure on this particular point?

Hornford: Yes, that gets to our first point, which was execution. We’ve talked in this group about the business struggle to execute. We also have to consider the ability of an enterprise architecture team to execute.

When we look at an organization that has historically come from and been very technically focused in enterprise IT, the struggle there, as Andrew said, is that it’s a self-perpetuating motion.

I keep running into architecture teams that talk about making sure that IT has a seat at the table. It’s a failure model, as opposed to going down the path that Len and Ahmed were talking about. That’s identifying the services that the business needs, so that they can be effectively assembled, whether that assembly is inside the company, partly with a outsource provider, or is assembled as someone else doing the work.

That gets back to that core focus of the sub-discipline that is evolving at an even faster rate than enterprise architecture. That’s business architecture. We’re 20 years into EA, but you can look at business literature going back a much broader period, talking about the difficulty of executing as a business.

This problem is not new. It’s a new player in it who has the capability to provide good advice, and the core of that I see for execution is an architecture team recognizing that they are advice providers, not doers, and they need to provide advice to a leadership team who can execute.

Gardner: Anyone else want to add to this issue of the role and importance of architect, be it business or be it information or IT, and this interesting catalyst position we are in between on- premises and outsource?

Varying maturity

Forde: I have a comment to make. It’s interesting listening to Dave’s comments. What we have to gauge here is that the state of EA varies in maturity from industry to industry and organization to organization.

For the function to be saying “I need a place at the table” is an indication of a maturity level inside an organization. If we’re going to say that an EA team that is looking for a place at the table is in a position to strategically advise the executives on what to do in an outsourcing agreement, that’s a recipe for disaster.

However, if you’re already in the position of being a trusted adviser within the organization, then it’s a very powerful position. It reflects the model that you just described, Dana.

Organizations and the enterprise architecture team at the business units need to be reflec
ting on where they are and how they can play in the model that Ahmed and Dave are talking about. There is no one-size-fits-all here from an EA perspective, I think it really varies from organization to organization.

Gardner: Nick, from the survey, was there any data and information that would lead you to have some insight into where these individuals need to go in order to accommodate, as Chris was saying, what they need to do from a self-starting situation to be able to rise to these issues even as these issues of course are variable from company to company?

Hill: One of the major focus areas that we found is that, when we talk about business architecture, the reality is that there’s a host of new technologies that have emerged with Web 2.0 and are emerging in grid computing, cloud computing, and those types of things that surely are alluring to the business. The challenge for the enterprise architecture is to take a look at what those legacy systems that are already invested in in-house and how an organization is going to transition that legacy environment to the new computing paradigms, do that efficiently, and at the same time be able to hit the business goals and objectives.

It’s a conundrum that the enterprise architects have to deal with, because there is a host of legacy investment that is there. In Infosys, we’ve seen a large uptake in the amount of modernization and rationalization of portfolios going on with our clientele.

That’s an important indicator that there is this transition happening and the enterprise architects are right in the middle of that, trying to coach and counsel the business leadership and, at the same time, provide the discipline that needs to happen on each and every project, and not just the very large projects or transformation initiatives that organizations are going through.

The key point here is that the enterprise architects are in the middle of this game. They are very instrumental in bringing these two worlds together, and the idea that they need to have more of a business acumen, business savvy, to understand how those things are affecting the business community, is going to be critical.

Gardner: Very good. We’re going to have to leave it there. I do want to thank you, Nick, for sharing the information from your Infosys Technologies survey and its result. So, thank you to Nick Hill, the Principal Enterprise Architect at Infosys Technologies.

I’d also like to thank our other members of our panel today. Len Fehskens, the Vice President of Skills and Capabilities at The Open Group. Thank you.

Fehskens: Thanks for the opportunity. It was a very interesting discussion.

Gardner: And Dave Hornford, the Architecture Practice Principal at Integritas. Thank you.

Hornford: Thank you very much, Dana, and everyone else.

Gardner: And Chris Forde, Vice President of Enterprise Architecture and Membership Capabilities at The Open Group. Thank you.

Forde: My pleasure. Thanks, Dana.

Gardner: And of course, we’ve also been joined by Andrew Guitarte. He is the Enterprise Business Architect of Internet Services at Wells Fargo Bank. Thank you.

Guitarte: My pleasure.

Gardner: And lastly, Ahmed Fattah. He is the Executive IT Architect in the Financial Services Sector for IBM, Australia.

Fattah: Thank you, Dana.

Gardner: And I want to thank our listeners who have been enjoying a sponsored podcast discussion in conjunction with The Open Group Conference here in San Diego, the week of February 7, 2011. I’m Dana Gardner, Principal Analyst at Interarbor Solutions. Thanks for joining and come back next time.

 

Webcast: Enterprise Architecture Management with TOGAF

For those that want to learn about Enterprise Architecture Management (EAM) alfabet who is a tools vendor is hosting a webcast on their thoughts on EAM. I would assume that they will illustrate that through their tool.
 
Enterprise Architecture Management with TOGAF

Register here

Friday, February 18, 2011,
2 pm (EST – New York time)
Length: 1 hour
Realize Your Business Vision Through Successful Transformation

alfabet and Detecon invite you to join our free Web Seminar: The Open Group Architecture Framework (TOGAF™) and alfabet planningIT – two success factors for your business transformation.
Find out how Enterprise Architecture (EA) based on TOGAF helps you face the challenges in business transformation. We will illustrate a holistic approach to handle your EA using a fictive Merger & Acquisition case study that is based on our many years of EA management consulting experience. You will also learn how EA is made tangible in an Enterprise Architecture Management solution: alfabet’s planningIT enables companies to understand, plan and transform their IT infrastructure.

Presenters:
Jan Foitzik, Director Partner Management, alfabet AG
Uwe Weber, Managing Partner, Detecon International GmbH

Click here to attend this free webinar on how EAM based on TOGAF can help you face today’s business challenges.

Note: Please note the time zone given and that the session lasts two hours.

 

Source: http://www.alfabet.com/news/events/togaf_eam_webinar

 

 

TOGAF a Registered Trademark and Surpasses 15k Certifications



Interesting news from the Open Group in regards to their TOGAF® enterprise architecture framework standard.

The Open Group just hit two major milestones for the architecture standard:

  1. The Open Group has announced via its blog that TOGAF® was recently granted registered trademark status.
  2. The TOGAF standard has now surpassed 15,000 certifications worldwide.

In the words of the Open Group this means:

Both of these achievements highlight not only the global recognition that TOGAF® has achieved as an framework for creating enterprise architectures and for helping IT professionals distinguish their skill sets, but the need companies have for finding more efficient ways of operating and saving money.