Category Archives: Enterprise Transformation

by | May 21, 2013 · 10:21 AM

What is Business Architecture? Part 2

By Allen Brown, President and CEO, The Open Group

I recently wrote that I had heard and read the opinions of a number of people about what is Business Architecture, as I am sure many of us have but I wanted to understand it from the perspective of people who actually had Business Architect in their job title.  So I wrote to 183 people in Australia and New Zealand and asked them.

The initial summary (blog) of the responses I received was focused on the feedback from Business Architects who were employed by organizations I think of as consumers; this one is focused on the feedback from consultants, ranging from those who are working on their own to others who are working with some of the largest consulting firms that we know.

Why I chose the countries I did and the questions I asked are contained in that earlier blog.

Again the responses have been amazing and thank you to everyone who took the time to do so.  They included some wonderful insights into their role and into their beliefs with respect to Business Architecture.

Summarizing the feedback from the consultants is even more difficult than that of the consumers.  Understandably, each of them has their own approach.  I have found it very difficult to decide what to leave out in order to get this down to a reasonable length for a blog.

It is important to repeat that I am still in the process of seeking to understand, so I would be really pleased to hear from anyone who has such a role, to correct any misunderstandings I might have or erroneous conclusions I may have drawn.

The first point of note from the responses is that Business Architecture is still evolving and finding its place in the enterprise.  While the consumers saw it as somewhere between immature and missing in action, the consultants tended to look at the how and why of its evolution.  In one case the view was that Business Architecture is evolving in response to a demand for greater business oriented control over transformation, while another reported, disappointedly, that business architecture is often seen as Business Process Review/Improvement on steroids.  Other comments included:

  • Generally Business Architecture is seen as business process review and/or business process improvement. There is not much real Business Architecture going on at the moment.
  • It is not widely understood at this point in time.  This first initiative will be conducted in a lightweight manner to gain the business buy in and get some projects onto the roadmap.  Delivery time will be a key factor in prioritization as we will be looking for some projects with shorter duration and lower complexity so some tangible benefits can be realized
  • It is not formally recognized.  Last year I was in the supply chain team (who also deal with Lean and other operational improvement skills).  We have Business Analysts, and a People and Change Team.  We have several areas than do Operating Models.  To me various elements of these would be included under the Business Architecture banner.

In common with the consumer viewpoint, the focus of Business Architecture is on the “What”.  Some of the comments included:

  • The Business Architecture will exist with or without technology, but as soon as technology is involved, the technology exists to service the business architecture, and the business architecture should be the input to the technology and application architecture.
  • Make recommendations of what projects the business should perform, in addition to relevant and timely corrections to the governance structure, business processes, and the structure of business information
  • The business architecture I am referring to is not the traditional element of the IT based Enterprise Architecture, but a framework that is totally business oriented and in which the whole business, including IT, can commit to in order to truly understand their problems and most of all the potential to genuinely improve the business.
  • “Business Architecture is not about telling people how to do their job at a detail level. Its function is to help us all to understand how together we can achieve the business goals and objectives
  • The primary focus of the Business Architect includes the analysis of business motivations and business operations, through the use of business analysis frameworks and related networks that link these aspects of the enterprise together. The Business Architect works to develop an integrated view of the business unit, in the context of the enterprise, using a repeatable approach, cohesive framework, and available industry standard techniques.

In some cases the focus of activity was the entire enterprise: the CEO view.  In others it was at the line of business or business unit level.  In all cases the focus was very much on the business issues:

  • Strategy
  • Business goals, objectives and drivers
  • Business operating model
  • Organization structure
  • Functions, roles, actors
  • Business processes
  • Key data elements

Being able to see the big picture and have the ability to communicate with key stakeholders was emphasized time and again.

  • Make it relevant and “makes sense” to senior management, operations and IT groups.  Visualize problems; have a way to communicate with the business team
  • Be able to relate – what big decision we need to make and to package it up so that execs can make a decision
  • The only person who cares about the whole picture is the CEO.  BA provides the CEO with a one page picture of the whole enterprise in a logical fashion
  • Show the CEO where impact is on a page – give confidence – control.  Help him make decisions around priorities.
  • The secret of good architecture is taking all the complexity and presenting it in a simplistic way that anyone can understand on a ‘need to know’ basis and quickly find the right answer to the current and/or planned state of business components.
  • BA facilitates strategic consistency with the business.  Where do we need to differentiate more than others?  How do we build in once or move to one instance?
  • Drive prioritization of when to invest based on the businesses strategic goals
  • Distil, communicate and relate to a business person
  • A key purpose of this new business driven architecture is to provide the means for communicating and controlling the strategic and operational intentions of the business in a way that is easy to understand for everyone in the organization

A common feature in the feedback is that underneath the models the information is rich – enables drill down – traceability to underlying requirements linked to the requirements.

Two areas of activity stood out the most: Capabilities and Value Streams.  Both of these are focused on WHAT a company needs to be able to do to execute its business strategy and to bring a product or service to a consumer.  Comments included:

  • Capabilities – combination of people, process and technology to deliver product features
  • Logical building blocks – gather information and compare the level of maturity in each capability, compare with others, understand where could we go to
  • Define/ champion 1 common reference model / capability model / logical building blocks of the enterprise.
  • Establish Capability, Information maps, Value Streams, stages and business processes.
  • Have intimate knowledge of the Business Capability (As Is/To Be), Business Component Structure, Business Processes, Value Streams and Conceptual Business Models.
  • Have the capability picture
  • … not only the capability of each component but also the relationship between components from every appropriate perspective (purpose, technical, compliance, risk, acceptability, etc.)
  • The Business Architecture is the first stage in a broader EA initiative.  Subsequent phases will align capabilities to applications and look at the major data flows between those applications

Since value stream mapping is a lean manufacturing technique, lean techniques are also called out as being relevant to business architecture because they identify areas of waste, which often change work processes or procedures, which may or may not impact applications and technology.  Feedback included:

  • Each value steam has Inputs (that triggers the value stream) and Outputs (the value based result of completing the business activities).
  • Each value stream is designed against Critical Success Factors, founded on the strategic intentions and priorities of the business, that represent the required business performance with Time, Cost, Quality, Risk and Compliance.
    • Time – How long the process should take from a Customer Perspective
    • Cost – How much the process should cost, measured using for example TDABC (Time Driven Activity Based Costing)
    • Quality – A statement clearly describing the (fit for) purpose of the activity
    • Risk – The protected acceptable residual risk involved due to effective control within the proposed design
    • Compliance – The specific interpreted requirements placed on the activity by interpreting the obligations of associated legislation and regulations.
    • Value streams are directed or informed by policies, plans, procedures, governance, regulations, business rules and other guidance, and are enabled by roles, IT Systems and other resources that will directly or indirectly support their completion.
    • The As-Is Architecture consists of the related value streams, indicating how the business is currently performing.   Under the facilitation of the business architect, design teams investigate how these can be improved to produce the Target State version of the Value Stream.

It was argued that displaying the relationship between the guidance, the enablers and the value streams, opens up the potential to discuss many things related to the business performance; that this alignment is critical for ensuring the business functions operate as expected; and that this is the major feature of business architecture and provides answers to so many previously unanswered questions for business managers.

Incidentally, since value stream maps are often drawn by hand in pencil (to keep the mapping process real-time, simple and iterative by allowing for simple correction) this tends to reinforce the comment by one of the consumer respondents that his most useful tools are pencil and paper.

The role and relationship of Business Architects, Business Analysts and other folk that might come under the general heading of Enterprise Architecture, varied from one organization to another, often seemingly dependent upon the size of the consulting firm.  At different ends of the spectrum were:

  • To a greater or lesser extent, Business Architects are supported by Business Analysts (“the knowledge processing factory) and by people with deep skills in design and process, Lean, 6 Sigma, HR, organization design and training.  The Business Architects ensure that all of the pieces fit together in a logical manor and that the impact can be shown in dollar terms
  • The Enterprise Architect is a person who can perform as both Solution Architect (SA) and a Business Architect (as needed) and has some ability as an Information Architect. In addition, an EA can perform at an enterprise level, something that is NOT required of either an SA or BA

The feedback on the title of Enterprise Architect was as varied as the number of responses.  The comments included:

  • Enterprise Architecture seen as a bad word
  • With hindsight, referring to it as architecture was a mistake
  • Enterprise Architecture is an IT version of technical specifications and drawings and not architecture, as such, and Enterprise Architects are mainly focused on the Application and Technology areas.
  • I think the technology story wave is coming to an end.  The focus will be more on the BusArch and InfoArch as that is where, in my view, the business IP sits. In the future more Bus/Info architects will become Enterprise WIDE architects, not so much enterprise architects

In most cases but not all, there is no such job as an Enterprise Architect.  It is in instead the overall term for Business Architects, Solution Architects, Information Architects, Value architects, Journey architects and so on.

The key differences that were highlighted between the roles of Business Architect and Enterprise Architect was a matter of depth and potentially also of education:

  • Enterprise Architects will tend to have more depth in technology; Business Architects will tend to have more depth in business techniques
  • Enterprise Architects will tend to have a Computer Science degree, or similar; Business Architects will tend to have a business degree or experience.

It was also stated that Business Architecture is a logical growth path for an experienced Business Analyst provided they get an Enterprise level understanding of the Business and Architecture.

When I actually look at the background of the respondents, I can see experience in:

  • IT consulting
  • Operations management
  • Product management
  • Project management
  • Business Analyst
  • Aeronautical Engineering
  • Logistics
  • … and much more besides

and education backgrounds are similarly varied.

The common theme is a deep interest in the business issues and what makes organizations work.

The evolution of Business Architecture clearly has a long way to go and depends upon the ability of the practitioners to relate to the business leaders.  One respondent predicted a shift and a segmentation in these comments:

  • For business that serve the “mum and dads”. I believe you will see a grouping of the different architectures based upon the business objectives and capabilities.
  • I think the technology story wave is coming to an end.  The focus will be more on the BusArch and InfoArch as that is where, in my view, the business IP sits. Applications and Technologies are all COTS nowadays (unless you are developing them). I think in the future more Bus/Info architects will become Enterprise WIDE Architects, not so much Enterprise Architects

The last word goes to the feedback that one Business Architect reported:

“In my time with this amazing new methodology I have had two separate reactions that stand out:

The first from an Acting CEO that was one of the biggest sceptics when I started the initiative and in admitting he had been, said that he owed me a big apology that he found the Business Architecture to be both highly useful and quite remarkable.

The second was in relation to a BPO initiative for a long standing traditional finance industry organization, when the chairman of the board said it [Business Architecture] had made a major decision relatively easy, that would have otherwise been one of the most difficult in the company‘s history.”

Allen Brown

Allen Brown is President and CEO, The Open Group – a global consortium that enables the achievement of business objectives through IT standards.  For over 14 years Allen has been responsible for driving The Open Group’s strategic plan and day-to-day operations, including extending its reach into new global markets, such as China, the Middle East, South Africa and India. In addition, he was instrumental in the creation of the AEA, which was formed to increase job opportunities for all of its members and elevate their market value by advancing professional excellence.

1 Comment

Filed under Business Architecture, Certifications, Enterprise Architecture, Enterprise Transformation, Professional Development, TOGAF

Tagged as , , , ,

by | May 14, 2013 · 10:45 AM

The Open Group Sydney – My Conference Highlights

By Mac Lemon, MD Australia at Enterprise Architects

Sydney

Well the dust has settled now with the conclusion of The Open Group ‘Enterprise Transformation’ Conference held in Sydney, Australia for the first time on April 15-20. Enterprise Architects is proud to have been recognised at the event by The Open Group as being pivotal in the success of this event. A number of our clients including NBN, Australia Post, QGC, RIO and Westpac presented excellent papers on leading edge approaches in strategy and architecture and a number of EA’s own thought leaders in Craig Martin, Christine Stephenson and Ana Kukec also delivered widely acclaimed papers.

Attendance at the conference was impressive and demonstrated that there is substantial appetite for a dedicated event focussed on the challenges of business and technology strategy and architecture. We saw many international visitors both as delegates and presenting papers and there is no question that a 2014 Open Group Forum will be the stand out event in the calendar for business and technology strategy and architecture professionals.

My top 10 take-outs from the conference include the following:

  1. The universal maturing in understanding the criticality of Business Architecture and the total convergence upon Business Capability Modelling as a cornerstone of business architecture;
  2. The improving appreciation of techniques for understanding and expressing business strategy and motivation, such as strategy maps, business model canvass and business motivation modelling;
  3. That customer experience is emerging as a common driver for many transformation initiatives;
  4. While the process for establishing the case and roadmap for transformation appears well enough understood, the process for management of the blueprint through transformation is not and generally remains a major program risk;
  5. Then next version of TOGAF® should offer material uplift in support for security architecture which otherwise remains at low levels of maturity from a framework standardisation perspective;
  6. ArchiMate® is generating real interest as a preferred enterprise architecture modelling notation – and that stronger alignment of ArchiMate® and TOGAF® meta models in then next version of TOGAF® is highly anticipated;
  7. There is industry demand for recognised certification of architects to demonstrate learning alongside experience as the mark of a good architect. There remains an unsatisfied requirement for certification that falls in the gap between TOGAF® and the Open CA certification;
  8. Australia can be proud of its position in having the second highest per capita TOGAF® certification globally behind the Netherlands;
  9. While the topic of interoperability in government revealed many battle scarred veterans convinced of the hopelessness of the cause – there remain an equal number of campaigners willing to tackle the challenge and their free and frank exchange of views was entertaining enough to justify worth the price of a conference ticket;
  10. Unashamedly – Enterprise Architects remains in a league of its own in the concentration of strategy and architecture thought leadership in Australia – if not globally.

Mac LemonMac Lemon is the Managing Director of Enterprise Architects Pty Ltd and is based in Melbourne, Australia.

This is an extract from Mac’s recent blog post on the Enterprise Architects web site which you can view here.

Leave a Comment

Filed under ArchiMate®, Business Architecture, Certifications, Conference, Enterprise Architecture, Enterprise Transformation, Professional Development, Security Architecture, TOGAF, TOGAF®

Tagged as , , , , , , , , , , ,

by | April 30, 2013 · 6:58 AM

What is Business Architecture?

By Allen Brown, President and CEO, The Open Group

I have heard and read the opinions of a number of people about what is Business Architecture, as I am sure many of us have but I wanted to understand it from the perspective of people who actually had Business Architect in their job title.  So I wrote to 183 people in Australia and New Zealand and asked them.

I chose Australia and New Zealand because of our conference in Sydney that was coming up at the time.  It is also worth mentioning that when counting the number of individuals in each country who have achieved TOGAF®9 certification, Australia is ranked 4th in the world and New Zealand is 20th.

I explained that I had thought of constructing a survey instrument but I always think that such an approach is only really suitable when you want to measure opinion on things that you know.  Since I really wanted to have an open mind, I asked everyone for their thoughts and provided a small number of open questions that showed the sort of thing I was interested in learning.

These were:

  • What is Business Architecture in the context of your organization?
  • Do you have Enterprise Architects in your organization? If so, what is it that you do that they do not? If not, how do you see Business Architecture differently from Enterprise Architecture?
  • Who do you report to? Is your line of reporting up to the CIO, the COO if you have one, or other senior level person?
  • How is Business Architecture perceived in your organization?

 It would also help me if I knew something about your organization.
  • Which industry are you in? e.g. IT, Oil, Finance, Healthcare, National or Local Government, etc.?
  • Is your organization primarily a consumer of Business Architecture or a supplier? e.g. consultant, trainer, vendor etc.
  • What type of organization do you work in? e.g. a for-profit entity, a government department, a charity, etc.
  • How big is the organization? Some idea of revenue or budget, number of employees – doesn’t have to be precise. You could just say small, medium or large.
  • How many Business Architects, Enterprise Architects or other architects are there in your organization?

And perhaps a little about yourself.
  • Your background e.g. Operations, Business Analysis, Project Management, IT, Finance etc.
  • Were you recruited for the role or did you develop into it?
  • I don’t wish to take up too much of your time but anything you can share would be very helpful. And please feel free to add anything else that you feel is relevant.

I have so far received 24 responses which is what I was hoping for but I am open to any other views people who are performing this role might have.  16 of the responses came from people employed by organizations that I think of as consumers of IT products and services (government departments, telcos, banks, accountants, energy companies, and mutuals) and 8 came from suppliers.

The responses were amazing and thank you to everyone who took the time to do so.  They included some wonderful insights into their role and into their organization, without of course divulging anything that they should not have.  But of course because I asked open questions, the responses are, at the same time both more complex and more interesting.  It’s a case of be careful of what you wish for – but I am really glad that I did.

So far I have been able to summarize the views of the consumers.  I will turn to the suppliers next.  It will be really interesting to see where the similarities and variations lay.

It is important to note that I am still in the process of seeking to understand, so I would be really pleased to hear from anyone who has such a role, to correct any misunderstandings I might have or erroneous conclusions I may have drawn.

A number of comments jumped out at me.  One example came from a Business Architect in a government department.  The reason it stood out was very simple.  Many times I am told that Business Architecture only applies to commercial business and cannot apply to governments or non-profits.  Which is strange to me, since I lead a non-profit and when I was at business school, part-time of course, a good proportion of my classmates were from the public sector.  The comment was in response to the question: who do you report to?  The answer was, “we report to the Secretary but all reporting lines are business focused”.

The first level of analysis, which should come as no surprise is that Business Architecture is a relatively new discipline for most organizations: in most cases it has been around for between 1 and 5 years.  Described by some as a growing capability, or as immature, or even as “largely missing”.  One respondent describes herself quite rightly as a pioneer.

A recurring theme was that the ability to have a company-wide or industry-wide model was critical as it provides a common terminology across the board to what the organization actually does and enables understanding of the implications of any changes.  Another was that the success or lack of it in Business Architecture really came down to the expertise of the people in the team; and another was that Business Architects acted very much, like internal consultants and often had a consulting background.

What Business Architects do is exactly that – their focus is on the “What”.  Some of the comments included:

  • Understanding strategic themes and drivers
  • Modeling value chains, value streams, configurations
  • Context modeling e.g. external interactions
  • Capabilities, including business capability, service capability (including both business and IT capabilities), capability maturity, targets and gaps
  • Calling out the interdependencies of all the business and architecture domains: strategy, governance, market, distribution, product, capability
  • Design – entities, people (organization structure, incentives), process, systems, functions, roles
  • Linking with and supporting the strategy and injecting into the investment planning cycle
  • The Business Architect provides processes, part of the input and information for the business to determine whether or not any investment will be made within their organisation

The “How” is in the domain of the Solution Architects, Application, Data and Technology Architects and the Business Analysts: business, process and data.

The crucial element is how well the Business Architects are integrated with the other architects and with the analysts.  In many cases Business Architecture was within the Enterprise Architecture function – as an aside it was pointed out by one or two respondents that they considered Enterprise Architecture as a function rather than a person – in other cases it was not.

The reporting lines for Business Architects varies from organization to organization.  Some reporting lines ultimately end up with the CIO or CTO, others to the COO and others did not.  In many cases they reported directly to a GM or Head of change management, transformation or business strategy or improvement.

In those cases where Business Architecture was not embedded within the Enterprise Architecture function the relationship was enabled via a forum or committee that brought the Business Architects together with those working on the other disciplines.   Gaining agreement on a common content framework, on business modeling standards and on governance procedures were cited as approaches that supported the collaboration.

Although in one case, Business Architecture was relegated to a sub-discipline of IT architecture to focus on the “business stuff”.  In most cases the Business Architects described a differentiated focus or role.

  • A focus on business performance, process design, organization design, strategy and planning
  • The documentation and governance of business processes, organizational elements, business requirements, regulatory requirements, business rules and risks
  • The description of what we are trying to do, what value it adds and how it can be done

The difference from the other architecture domains was often described under the general heading of technology.

  • Technical architecture and governance
  • Strategic solutioning
  • Information, application, data architecture
  • Portfolio management
  • The enterprise stack of tools
  • Innovation through new technology

Business Architecture often demands a certain amount of analysis work and in one case it was seen as glorified business analysis. I have also heard “industry experts” say that they do not understand the difference between Business Architects and Business Analysts.  But that is unfair both to the Business Architects and to the Business Analysts.  They are both important functions in their own right.  In fact it has been emphasized that you need all three disciplines: Business Analyst, Business Architect and the Solution, Information, Technology Architect.

Perhaps in smaller organizations you might get by with a Jack of all trades but the size of the organization represented by these respondents ranged from 1,500 employees to 50,000 employees and they need the benefit of the three different specializations.

While the Business Analysts are the source of the very detailed information needed, the Business Architect brings the skills needed to distil that information and discuss it with the business leaders.  The people they are talking with are the senior leaders, the strategic solutioning teams, the program directors of large change programs and others who need pragmatic, easily digestible information.  They need to understand the implications and gaps, the dependencies, the opportunities and the limitations.

As one person said, “the success gauge for Business Architecture is an organization that starts solving business problems by defining them within the organization’s context across the spectrum of change areas, minus the technology change area, and then works toward the technology, rather than starting at a technology solution that might solve the problem and playing catch-up from there.  I continue to hold to the view that investing in the Business Architecture up front saves on people, process and technology cost at the end.”

Again, I would like to thank everyone for taking the time to respond.  Everyone has a valuable story to tell and everyone is fully committed to the role and function of the Business Architect.  If I have misunderstood anything, please do not hesitate to correct me. I look forward to hearing your comments.

Allen Brown

Allen Brown is President and CEO, The Open Group – a global consortium that enables the achievement of business objectives through IT standards.  For over 14 years Allen has been responsible for driving The Open Group’s strategic plan and day-to-day operations, including extending its reach into new global markets, such as China, the Middle East, South Africa and India. In addition, he was instrumental in the creation of the AEA, which was formed to increase job opportunities for all of its members and elevate their market value by advancing professional excellence.

2 Comments

Filed under Business Architecture, Certifications, Enterprise Architecture, Enterprise Transformation, Professional Development, TOGAF

Tagged as ,

by | August 8, 2012 · 3:30 AM

ArchiMate 2.0 – Ready for the Future of Enterprise Architecture!

By Henry Franken, BIZZdesign

Models have played an important role in business for a long time. Process models, information- and data models, application landscapes, strategic models, operational models – you name it, organizations have tried it. With the rise of Enterprise Architecture (EA) as a strategic discipline for many organizations, we saw two interesting developments. First of all, organizations try to connect their models, to gain insight in the way the enterprise works from many different perspectives. Secondly, we saw the trend that models become more high-level, focusing on the essence of the organization.

These developments have led to the development of the ArchiMate® language, which allows high-level modeling within a domain, but allows modeling the relations between domains. Even more, in recognition that architecture is a communications game, a key driver for the language was to also allow for effective visualizations for key stakeholders based on solid architectural analyses.

The first edition of the ArchiMate language enabled organizations to create holistic architecture models with concepts from three domains: business, application and technology. With a handful of concepts and relations, this allowed organizations to model the relation between products and services, processes, supporting applications and information, as well as infrastructure. Having modeled this formally, organizations can do impact assessments, generate visualizations for various stakeholders and so on.

ArchiMate has recently been extended by members within the ArchiMate Forum within The Open Group), resulting in ArchiMate 2.0 – a new version of ArchiMate that is fully aligned with The Open Group Architecture Framework (TOGAF®). Two new extensions have been developed for this purpose, making sure the language now covers the entire Architecture Development Method (ADM) of TOGAF.

The new motivation extension allows organizations to graphically model the answer to the “why” question of EA: Who are key stakeholders of EA? What are their drivers? How do these drivers lead to principles and requirements that are realized in the architecture? This extension mainly aligns with the early phases of the TOGAF ADM.

The new ArchiMate 2.0 standard also has an implementation and migration extension that aligns with the later phases of the ADM. Using this extension, architects can align with project management and graphically model plateaus, projects and programs, as well as their deliverables.

One of the key strengths of ArchiMate – as well as TOGAF – is its openness – it allows practitioners worldwide to join in and help push the language forward. Indeed, we are seeing the adoption of the language, as well as certifications of practitioners grow worldwide.

The Open Group has introduced certification programs for individuals, training vendors and tool vendors, and the uptake of these programs is very successful! We are now seeing many individuals obtaining an ArchiMate 2.0 certificate, training vendors applying for training accreditation, and tool vendors implementing the ArchiMate modeling language into Enterprise Architecture modeling tools, all while  being certified by The Open Group.

With all these great developments within the last few years – fluent integration with TOGAF and a fast growing number of professionals using ArchiMate – I believe it is safe to say that with ArchiMate 2.0 you are ready for the future of Enterprise Architecture!

Henry Franken is the managing director of BiZZdesign and is chair of The Open Group ArchiMate Forum. As chair of The Open Group ArchiMate Forum, Henry led the development of the ArchiMate Version 2.o standard. Henry is a speaker at many conferences and has co-authored several international publications and Open Group White Papers. Henry is co-founder of the BPM-Forum. At BiZZdesign, Henry is responsible for research and innovation.

4 Comments

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

Tagged as , , , , , ,

by | August 1, 2012 · 9:45 AM

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:

Leave a Comment

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

Tagged as , , , , , , , , ,

by | June 22, 2012 · 12:11 PM

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.

Leave a Comment

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

Tagged as , , , , , , , , ,

by | May 3, 2012 · 12:30 AM

Video Highlights of Day 2 at the Cannes Conference

By The Open Group Conference Team

How important is top-down buy-in when building a strategy for enterprise transformation? The Day 2 speakers of The Open Group Conference in Cannes address this question, and Peter Haviland, chief architect and head of business architecture within Ernst & Young’s Advisory Services practice, summarizes each of the plenary sessions, including:

  • “IT Capacity Build Up and Enterprise Architecture Enablement – Transformation at Ministry of Foreign Affairs” by Saeed Al Daheri, IT director of the UAE Ministry of Foreign Affairs
  • “World Class EA 2012: Putting Your Architecture Team In the Middle of Enterprise Transformation” by Peter Haviland, chief architect and head of business architecture advisory services at Ernst & Young, U.S.
  • “Future Airborne Capability Environment (FACE™): Transforming the DoD Avionics Software Industry Through the Use of Open Standards” by Kirk Avery, Lockheed Martin and Judy Cerenzia, The Open Group

1 Comment

Filed under Conference, Enterprise Architecture, Enterprise Transformation, FACE™

Tagged as , , , , , , , , , , , , , ,

by | April 25, 2012 · 9:07 AM

Cannes Conference Day 2: Proactively Engaging in the Transformation Process Paramount for Enterprise Architects

By The Open Group Conference Team

After the conference’s first night on the French Riviera, Day 2 of the Cannes Conference continued with the theme of transformation. The first plenary session led by Dr. Saeed Al Daheri, IT director of the United Arab Emirates Ministry of Foreign Affairs (MOFA), examined how one of the world’s emerging countries emphasized the alignment of IT and strategy.

MOFA wanted to increase performance by building up process, people and technology. Dr. Al Daheri was in charge of this project and decided to focus on three key initiatives: establishing EA, building IT capacity and running quick wins. MOFA wanted its Enterprise Architecture (EA) program to become central to the operation of IT and to have a mandate over all domains of the enterprise, including business strategy all the way down to business processes. EA provided the foundation to align IT and business, which was considered to be of paramount importance.

As with most major transformations within an organization, Dr. Al Daheri and his team faced several key challenges, which included leadership endorsement, recruitment and IT culture and the traditional view of IT. Through clear communication and education, the project received a top-down mandate that helped them receive buy-in from key stakeholders, which was essential for success. Regarding recruiting, the skills of an architect were hard to come by, especially one who speaks Arabic, so in order to succeed the IT department added 10 new positions to support this initiative and created a training program to develop the skill of existing staff. And finally through more proactive engagement with the rest of MOFA and by anticipating business needs and outlining clear roles and responsibilities, IT was able to work hand-in-hand with the business to achieve the ultimate goal of increased performance.

Through careful planning and proper implementation, MOFA was able to reduce vendor selection to 5 weeks, realize 26% cost savings and reduce project time by 17% – truly transformative results that were achieved through IT and business alignment.

A New Approach to EA: Less Thinking, More Doing

In the second plenary session, Peter Haviland, chief architect and head of business architecture within Ernst & Young‘s Advisory Services, along with two colleagues, Mick Adams and Garth Emrich, presented “World-Class EA 2012: Less Thinking, More Doing.” There’s a lot of talk of enterprise transformation, but how involved are enterprise architects in this process? Haviland started the presentation by asking the question, “How many architects are truly seeking out proactive opportunities?”

Haviland argued that EA is in prime position to help transform organizations through the improvement of the execution of strategy across business functions and the investment in process, tools, training and IT. But in order to do so, architects need to seek out opportunities to become a crucial part of enterprise transformation. Haviland listed out four questions that architects need to ask themselves to become more proactive.

  • What’s the context? Understanding the context of the situation is key to enabling enterprise transformation. EAs need to take a step back and look at the bigger picture, rather than purely focusing on building models. This will ensure alignment with the overall business strategy.
  • How do you flex your capability? Once you have completed your situational analysis, how can your skills translate into producing the desired results? Using your skills to help the enterprise achieve its goal of enterprise transformation will ultimately raise the visibility of EA within your organization.
  • What are the risks, opportunities and costs? E&Y recently completed a global survey that explored the top 10 risks that can be turned into opportunities, with the number one risk being regulation and compliance. It’s essential to understand the risks, opportunities and costs before embarking on enterprise transformation, for that is where the biggest gains can be realized.
  • If I’m an architect, what do I want to own? Assess the project and determine where your skill set will provide the biggest overall impact. This will allow you to provide the most value as an architect and set you up for success.

Being more proactive will help architects not only become a more integral part of your organization, but it will also establish EA as a key driver of enterprise transformation.

How to Create Value in the FACE™ of Shrinking Government Budgets

Improving performance while cutting costs – this is the mandate of most organizations these days, including governments. While budget cuts to the U.S. Department of Defense (DoD) budget require them to scale back on new platforms and funding for military technology procurements, the need for civilian safety and military performance continues to be a top priority. But how can the DoD do more with less?

Judy Cerenzia, The Open Group program director for the Future Airborne Capability Environment (FACE) Consortium, and Kirk Avery, chief software architect for Lockheed Martin Mission Systems and Sensors, addressed this question during final plenary session of the day. This session examined how FACE was able to help the DoD and the avionics industry provide complex mission capability faster in an environment of shrinking budgets.

In order to achieve this goal, FACE saw the need to transform the operating environment by developing a common operating environment (COE) to support applications across multiple DoD avionics systems – something that had never been done before. After reaching out to the DoD and other stakeholders including corporations that produce military components, FACE concluded that a successful COE would enable real time operating systems, stability, competition to prevent vendor lock-in, the ability to withstand extreme environmental conditions and a system life that spans many years.

With this in mind, FACE set out to develop a non-proprietary open environment that enabled a flexible software open systems architecture. The hard work of the consortium, which was established in June 2010, resulted in the creation of the FACE Business Guide and the recently released FACE Technical Standard. Both deliverables have helped the DoD and the avionics industry achieve their goal of providing complex mission capability faster with less budget and realize other benefits that include:

  • Reduction of time to field capabilities of new technologies
  • Interoperable software components within the environment
  • Portability of software components across an avionics platforms
  • Reduction of integration effort, schedule and cost
  • Enablement of truly open software components in existing and future avionics systems

Transformation within the government is quite an accomplishment, and FACE is looking to further develop common operating environments through continued collaboration between government and the avionics industry.

A Day 2 video recap by Peter Haviland will be published soon. To view the full list of conference sessions, please visit http://www3.opengroup.org/cannes2012

1 Comment

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

Tagged as , , , , , , , , , , , , , ,

by | April 24, 2012 · 7:06 AM

Cannes Conference Day 1: Communication Key for Business Transformation, According to Open Group Speakers

By The Open Group Conference Team

Video recap by Dave Lounsbury, CTO of The Open Group

Much like the wind that blows through the Côte d’Azur, talk of business transformation swept through Cannes like a warm breeze yesterday as Day 1 of The Open Group Cannes Conference concluded. The underlying theme of the day was communication and shared languages – a common concept for all enterprise architects, but this time with a slight twist.

Innovator Dr. Alex Osterwalder presented the first session of the day entitled “Business Models, IT and Enterprise Transformation,” which discussed concepts from his well-known book “Business Model Generation.” As Dr. Osterwalder explained, often times there’s a language gap between IT and strategy when it comes to business models, which is why long meetings are largely unproductive.

Dr. Alex Osterwalder explaining the business model canvas

Dr. Osterwalder stressed the importance of simplicity in models, meaning that business models should be created in such a way that anyone in the company can understand them upon first glance. This is the basis for a concept Osterwalder calls the business model canvas, a literal illustration of an organization’s business model using the following key assets – key partners, key activities, key resources, value propositions, customer relationship, channels, customer segments, cost structure and revenue streams.

The audience was then encouraged to work in pairs and use the business model canvas to break down the business model of one participant. Each group had eight minutes to map out the nine components on a large sheet of paper representing the business model canvas using post-its. The audience enjoyed this exercise, which demonstrated that creating a business model does not have to be a laborious process, and that simple is often times best.

Dr. Osterwalder went on to discuss real-life examples such as Apple’s iPod and Nestle Nespresso, dissecting each company’s business model utilizing the business model canvas to learn why both endeavors were so successful. Apple was disruptive because as Steve Jobs said when the first iPod was released, “It’s a thousand songs in your pocket.” The iPod created a dependency on the product and the iTunes service, and one of the unknown factors of the customer relationships was that iTunes made it so easy to upload and manage your music that the barrier to transfer services was too high for most consumers. Nespresso’s business model was built on the creation of the single drink aluminum cans, the product’s key resource, which are only made by Nespresso.

Companies of all sizes have used the business model canvas to adjust their business models, including Fortune 500 companies and government organizations, and Dr. Osterwalder thought that enterprise architects can act as a bridge between strategy and IT facilitating communication between all facets of the business and overseeing the management of business models.

BNP Paribas saves 1.5B Euro through Careful Business Transformation

In the next plenary session, Eric Boulay, CEO of Arismore, and Hervé Gouezel, Advisor to the CEO of BNP Paribas, looked at how enterprise architects can do a better job of presenting CEOs with Enterprise Architecture’s value proposition. Conversely, Boulay stated that the CEOs also need to outline what expectations need to be met by enterprise architects in order to enable business transformation via enterprise architects.

Boulay argued that a director of transformation is now needed within organizations to manage and develop transformation capability. The results of Enterprise Architecture must be merchandised at the C-level in order to communicate business value, and the director of transformation would be enable architects to continue to invent through this new role.

In the same session, Hervé Gouezel discussed the 2009 merger of BNP Paribas and Fortis Bank and the strategy that went into creating a somewhat seamless transition. The original plan had three phases: phase 1 – take six days to pick new management and six weeks to define taskforces, workgroup organizations and stabilization measures; phase 2 – take six months to plan and synergize; and phase 3 – implement projects and programs over a three year period.

Needless to say, this was a huge undertaking, and the goal of the three-phase process was to save the company 500 million Euros. With careful planning and implementation and by following the three-phased approach, BNP Paribas saved over 1.5 billion Euros – three times the targeted amount! This goes to show that careful planning and implementation can lead to true business transformation.

The Semantics of Enterprise Architecture

Len Fehskens, VP of skills and capabilities at The Open Group, presented the final plenary of the day. Fehskens revisited Enterprise Architecture’s most basic, yet seemingly impossible question: How do you define Enterprise Architecture?

Bewildered by the fact that so many different opinions exist around a discipline that nominally has one name, Fehskens went on to discuss the danger of assumptions and the fact that assumptions are rarely made explicit. He also exposed the biggest assumption of all: We’re all sharing the same assumptions about Enterprise Architecture (EA).

Fehskens urged architects to remain open-minded and be aware of the differing perspectives regarding what EA is. The definition of Enterprise Architecture at this point encompasses a variety of opinions, and even if your definition is “correct,” it’s necessary for architects to understand that logical arguments do not change strongly held beliefs. Fehskens ended the session by presenting the teachings St. Augustine, “Let us, on both sides, lay aside all arrogance. Let us not, on either side, claim that we have already discovered the truth. Let us seek it together as something which is known to neither of us. For then only may we seek it, lovingly and tranquilly, if there be no bold presumption that it is already discovered and possessed.”

In other words, Fehskens said, before Enterprise Architecture can move forward as a discipline and fulfill its potential within the enterprise, architects must first learn to agree to disagree regarding the definition of EA. Communication must first be established before true business transformation (and the value of EA) can be realized.

Day 2 of the conference looks to be equally exciting, continuing the theme of enterprise transformation. To view the sessions for the remainder of the conference, please visit: http://www3.opengroup.org/cannes2012

3 Comments

Filed under Conference, Enterprise Architecture, Enterprise Transformation

Tagged as , , , , , , , , , , ,

by | March 30, 2012 · 12:30 AM

Enterprise Transformation Takes the French Riviera

By The Open Group Conference Team

The Open Group Conference in Cannes, France is just around the corner. Taking place April 23-27, the conference will bring together leading minds in technology to discuss the process of Enterprise Transformation, and the role of Enterprise Architecture (EA) and IT in Enterprise Transformation.

The French Riviera is a true playground for the rich and famous. As the location of the next Open Group Conference, (not to mention the next Open Cannes Awards) it seems only fitting that we not only have an incredible venue for the event, the JW Marriott Cannes, but have our own star-studded lineup of speakers, sessions and activities that are sure to make the conference an unforgettable experience.

In addition to tutorial sessions on TOGAF and ArchiMate, the conference offers roughly 60 sessions on a varied of topics, including:

  • Enterprise Transformation, including Enterprise Architecture and SOA
  • Cybersecurity, Cloud Security and Trusted Technology for the Supply Chain
  • Cloud Computing for Business, Collaborative Cloud Frameworks and Cloud Architectures

The conference theme “Enterprise Transformation” will highlight how Enterprise Architecture can be used to truly change how companies do business and create models and architectures that help them make those changes. Keynote speakers include:

  • Dr. Alexander Osterwalder, Best-selling Author and Entrepreneur

Dr. Osterwalder is a renowned thought leader on business model design and innovation. Many executives and entrepreneurs and world-leading organizations have applied Dr. Osterwalderʼs approach to strengthen their business model and achieve a competitive advantage through business model innovation. His keynote session at the conference, titled: “Business Models, IT, and Enterprise Transformation,” will discuss how to use the Business Model Canvas approach to better align IT and business strategy, empower multi-disciplinary teams and contribute to Enterprise Transformation.

  • Herve Gouezel, Advisor to the CEO at BNP Paribas & Eric Boulay, Founder and CEO of Arismore

Keynote: “EA and Transformation: An Enterprise Issue, a New Role for the CIO?” will examine governance within the Enterprise and what steps need to take place to create a collaborative Enterprise.

  • Peter Haviland, Chief Architect and Head of Business Architecture Advisory Services at Ernst & Young, US

Keynote: “World Class EA 2012: Putting Your Architecture Team in the Middle of Enterprise Transformation,” will identify and discuss key activities leading practice architecture teams are performing to create and sustain value, to remain at the forefront of enterprise transformation.

  • Kirk Avery, Software Architect at Lockheed Martin & Robert Sweeney, MSMA Lead Systems Engineer at Naval Air Systems Command

Keynote: “FACE: Transforming the DoD Avionics Software Industry Through the Use of Open Standards,” will address the DoD Avionics Industry’s need for providing complex mission capability in less time and in an environment of shrinking government budgets

The Common Criteria Workshop and the European Commission

We are also pleased to be hosting the first Common Criteria Workshop during the Cannes Conference. This two-day event – taking place April 25 to 26 – offers a rich opportunity to hear from distinguished speakers from the Common Criteria Security community, explore viewpoints through panel discussions and work with minded people towards common goals.

One of the keynote speakers during the workshop is Andrea Servida, the Deputy Head of the Internet, Network and Information Security unit with the European Commission in Brussels, Belgium. With extensive experience defining and implementing strategies and policies on network and information security and critical information infrastructure protection, Mr. Servida is an ideal speaker as we kick-off the first workshop.

The Open Cannes Awards

What trip would be complete to Cannes without an awards ceremony? Presented by The Open Group, The Open Cannes Awards is an opportunity for our members to recognize each other’s accomplishments within The Open Group with a little fun during the gala ceremony on the night of Tuesday, April 24. The goal is to acknowledge the success stories, the hard work and dedication that members, either as individuals or as organizations, have devoted to The Open Group’s ideals and vision over the past decade.

We hope to see you in Cannes! For more information on the conference tracks or to register, please visit our conference registration page, and please stay tuned throughout the next month as we continue to release blog posts and information leading up to The Open Group Conference in Cannes, France!

Leave a Comment

Filed under Cloud, Cloud/SOA, Conference, Cybersecurity, Enterprise Architecture, Enterprise Transformation, FACE™, Semantic Interoperability, Service Oriented Architecture

Tagged as , , , , , , , , , ,

by | March 27, 2012 · 12:30 AM

Enterprise Transformation, Innovation, Emergence and the Sewers of Vienna

By Stuart Boardman, KPN 

Enterprise transformation is a topic central to The Open Group’s agenda these days, so I don’t suppose the following assertion is exactly radical. The success of transformation starts by understanding the drivers for change, the goals of the transformation and the factors that can be expected to have a positive or negative influence on it.

Transformation doesn’t necessarily have to involve innovation but it often does. Sometimes innovation is itself a driver for transformation. For some organizations innovation is a fundamental part of their business model. Apple, for example, wouldn’t have survived without it. You can have the best user interface and the grooviest products but to reach a wider market or indeed to get your existing market to buy new stuff, you need to keep innovating. And to do that well you have to enjoy doing it and you have to understand how it works.

Once upon a time, giants like the old IBM and the old Microsoft didn’t need to do that, because they owned so much of the market. But that’s changed too, because, partly as a result of their own competition, there is now an ecosystem of all kinds of players (from a Google or an Apple to the huge number of startups and app developers), who can and do come out of left field with disruptive innovation. And this isn’t only true in the technology world.

These days it’s hard to read about innovation without coming across the concept of emergence. Emergent innovation develops through interaction in an ecosystem and cannot simply be explained by looking at what each individual member of the ecosystem does. This kind innovation is in a sense serendipitous and is never going to be achieved via the traditional R&D approach. It’s cheaper and faster than that and, exactly because of the way it has developed, more likely to be of immediately applicable value. Achieving transformation with emergent innovation is about the ability to recognize, adopt, adapt and “productize” that innovation. This applies equally whether the innovation is outwardly (product/service) or inwardly (operations) oriented.

Back to transformation. We need, as I said, to be able to understand the factors that will positively or negatively affect the success of our transformation. If we haven’t properly understood them, they might turn out to be very urgent drivers for (re)transformation.

At the beginning of this century mobile communications providers were trying to transform their business models and operations in order to get their share of the internet revolution. They wanted to reach a new market and to escape the trap of becoming just a “bit pipe” for other people’s value added services. The operators spent a lot of money on 3G. The equipment manufacturers spent a lot of money developing new phones and interfaces. By 2003 we already had all the necessary technological capabilities and there was no shortage of marketing but it simply didn’t take off.

Why? It wasn’t really cost, because, when the iPhone arrived a few years later and turned everything around, data was still expensive (and the phone even more so). And it wasn’t really speed or usability, because the download speed was adequate for the services on offer and there were some pretty nifty devices. It just wasn’t very interesting. There was simply not enough valuable content available to justify the outlay. So the operators just reverted to milking the reliable voice and text cow.

When the iPhone arrived, what really made the difference was the ecosystem that came with it. Suddenly there was a world of app developers producing things people didn’t know they needed but discovered were cool. And there was the App Store that made it easy to get your product to market and easy for the customer to discover it. Yes, of course it was a groovy device and a revolutionary interface but without the ecosystem it would have been restricted to a market of Apple fans and people with lots of money to spend on looking hip.

So then what happened? Well the mobile operators (those who could get their hands on the device) finally started getting a return on their investment in 3G. What was largely a new group of smartphone manufacturers (HTC, Samsung, LG etc.) rushed to produce their own versions. And then Google came along with Android and we finally had a really large ecosystem built around innovation.

With that came another form of emergence as the users and the app developers started discovering all kinds of things you could do with these devices and the information available on and via them. That had a negative influence on the mobile operators’ revenues, as people used a whole range of IP based services (with the Mbs paid for in their monthly bundle) to avoid the expensive voice and text services. This was something the operators had ignored, even though they’d predicted years before that it would happen, which of course was exactly what provoked the earlier attempted transformation. In other words, they failed to understand what was going on in their ecosystem and how it might affect them.

All organizations inhabit an ecosystem consisting of their customers, partners, suppliers and in many cases legal and regulatory bodies (and arguably their competitors too). Ecosystems are really the heart of this blog, so here’s a definition. An ecosystem is a collection of entities, whose members are (at least partially) interdependent. Specifically we’re looking at what Jack Martin Leith calls a Business Ecosystem. Jack’s definition is further amended by Ruth Malan to “A business ecosystem is a network of organizations that affect each other, possibly indirectly.” What we see today is that for many (maybe most) organizations the ecosystem is becoming bigger and more diffuse. Apart from the examples above, this is apparent in the extended enterprise, Cloud and social business – and the effect is amplified by emergence.

Now one of the things about an ecosystem is that not all the members are necessarily aware of each other. But as the definition makes clear, they all have an influence on and are influenced by the ecosystem as a whole. Each organization has its own view on the ecosystem, which really defines its enterprise. That doesn’t mean it can’t be affected by what goes on elsewhere in the ecosystem.

A little while ago Peter Bakker published a provocative little blog with the title “Infrastructure Architecture is way more important than Enterprise Architecture.” After a flurry of comments and replies, I understood that Peter was talking about the infrastructure of complete ecosystems. He used the example of the infrastructure of the City of New York. It consists of all the road, rail and waterways, the transportation services (passengers and freight), construction and maintenance services, energy supply, port and harbor services and planning, regulatory and licensing activities. And that’s leaving aside the electronic communications infrastructure and the voice, data and TV services that run on it. These products and services are delivered by multiple providers (commercial organizations, the city council and other public bodies), who are all part of an ecosystem, which also includes the users of the infrastructure (people and organizations including of course the providers themselves). So yes, this infrastructure is much bigger than any one of the enterprises that contributes to it and it is critical to the health of the ecosystem (the efficient functioning of the City of New York) in a way that no individual member could be – not even the City Council.

But that information isn’t much use to us unless we can do something with it. So I set off on a journey to see if I could find a way of modeling such an ecosystem as a sort of Enterprise Architecture. That probably sounds a bit grandiose but you need to see this as just a set of techniques, which could help us create a usable and meaningful overview of an ecosystem – something you can project your proposed changes onto.

It’s not about details. Even if I thought one could capture all the details, the result would be unmanageable and therefore unusable! So the detailed view is constrained to the individual enterprise from whose perspective one is viewing this.

The journey’s just begun. I’ve built the basics of the story, which is about the mythical city of Metropolis. I’m sticking to this city infrastructure example, because it’s familiar to everyone and doesn’t need too much background explanation. I’m now looking at the techniques that might be useful in achieving this. I’m looking at and have started working on Customer Journeys. If you’re interested, you can find some text here and images here.

I think it will be very useful to create a Business Model Canvas (or some similar technique of your preference) for some or all of the organizations involved. In the most cases we’d be looking at generic organization types. So for, example, there won’t be a canvas for every single bus company but the fact that there usually are multiple passenger transport companies means that competition is an important factor.

So we probably need an additional model, which is capable of taking that into account – like Tom Graves’s Enterprise Canvas. I’m also considering a service model (what are all the relevant services, how do they interact, etc.). Stafford Beer’s Viable Systems Model may be a good way to capture the system as a whole, so I’m working on that now. I’d be only too pleased to exchange ideas about the whole approach with anyone who doesn’t think I’ve taken leave of my senses – and maybe even with those who do! My thanks to Jack, Ruth, Peter, Tom and Charles for the good ideas and encouragement. Please don’t blame them, if you think it’s rubbish.

So finally – you might be wondering what this has to do with the sewers of Vienna. If you’ve seen The Third Man, you might figure it out. For those who haven’t: in the film Orson Wells plays Harry Lime, a wanted man in the Western sector of post-war Vienna. He fakes his death and disappears to the Russian controlled East – and continues his operation in the West using the sewer system to get across (under) the city avoiding all control posts and remaining effectively invisible. It’s just a somewhat lighthearted example of an innovative (one might say emergent) transformation of an infrastructure to serve a totally different purpose. And it does illustrate how you can get caught out if you don’t understand your ecosystem properly.

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. 

8 Comments

Filed under Enterprise Architecture, Enterprise Transformation

Tagged as , , , , , ,

by | March 20, 2012 · 12:30 AM

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

By Serge Thorn, Architecting the Enterprise

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

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

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

First, the entities from the TOGAF 9.1 metamodel:

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

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

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

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

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

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

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

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

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

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

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

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

Leave a Comment

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

Tagged as , , , , , , , , , , , ,

by | March 15, 2012 · 12:30 AM

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

By Serge Thorn, Architecting the Enterprise

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

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

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

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

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

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

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

More spending on innovation

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

Enabling strategic business goals via better operational excellence

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

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

Customer intimacy

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

Greater product leadership

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

Comply with regulatory requirements

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

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

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

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

2 Comments

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

Tagged as , , , , , , , , ,

by | March 13, 2012 · 12:30 AM

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

By Serge Thorn, Architecting the Enterprise

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

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

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

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

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

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

Without Enterprise Architecture you can probably NOT fully achieve:

IT alignment with the business goals

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

Integration

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

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

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

Change management

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

Reduced time to market and increased IT responsiveness

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

Better access to information across applications and improved interoperability

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

Readily available descriptive representations and documentation of the enterprise

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

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

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

3 Comments

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

Tagged as , , , , , , ,

by | February 22, 2012 · 1:50 PM

Enterprise Architecture and Enterprise Transformation: Related But Distinct Concepts That Can Change the World

By Dana Gardner, Interarbor Solutions

For some, if you want enterprise transformation, you really need the organizing benefits of Enterprise Architecture to succeed.

For others, the elevation of Enterprise Architecture as an essential ingredient to enterprise transformation improperly conflates the role of Enterprise Architecture, and waters down Enterprise Architecture while risking its powerful contribution.

So how should we view these important roles and functions? How high into the enterprise transformation firmament should Enterprise Architecture rise? And will rising too high, in effect, melt its wings and cause it to crash back to earth and perhaps become irrelevant?

Or is enterprise transformation nowadays significantly dependent upon Enterprise Architecture, and therefore, we should make Enterprise Architecture a critical aspect for any business moving forward?

We posed these and other questions to a panel of business and EA experts at last month’s Open Group Conference in San Francisco to deeply examine the fascinating relationship between Enterprise Architecture and enterprise transformation.

The panel: Len Fehskens, Vice President of Skills and Capabilities at The Open Group; Madhav Naidu, Lead Enterprise Architect at Ciena Corp.; Bill Rouse, Professor in the School of Industrial and Systems Engineering and the College of Computing, as well as Executive Director of the Tennenbaum Institute, all at the Georgia Institute of Technology, and Jeanne Ross, Director and Principal Research Scientist at the MIT Center for Information Systems Research.

Here are some excerpts:

Gardner: Why is enterprise transformation not significantly dependent upon Enterprise Architecture, and why would it be a disservice to bring Enterprise Architecture into the same category?

Fehskens: My biggest concern is the identification of Enterprise Architecture with enterprise transformation.

First of all, these two disciplines have different names, and there’s a reason for that. Architecture is a means to transformation, but it is not the same as transformation. Architecture enables transformation, but by itself is not enough to effect successful transformation. There are a whole bunch of other things that you have to do.

My second concern is that right now, the discipline of Enterprise Architecture is sort of undergoing — I wouldn’t call it an identity crisis — but certainly, it’s the case that we still really haven’t come to a widespread, universally shared understanding of what Enterprise Architecture really means.

My position is that they’re two separate disciplines. Enterprise Architecture is a valuable contributor to enterprise transformation, but the fact of the matter is that people have been transforming enterprises reasonably successfully for a long time without using Enterprise Architecture. So it’s not necessary, but it certainly helps. … There are other things that you need to be able to do besides developing architectures in order to successfully transform an enterprise.

Gardner: As a practitioner of Enterprise Architecture at Ciena Corp., are you finding that your role, the value that you’re bringing to your company as an enterprise architect, is transformative? Do you think that there’s really a confluence between these different disciplines at this time?

Means and ends

Naidu: Transformation itself is more like a wedding and EA is more like a wedding planner. I know we have seen many weddings without a wedding planner, but it makes it easier if you have a wedding planner, because they have gone through certain steps (as part of their experience). They walk us through those processes, those methods, and those approaches. It makes it easier.

I agree with what Len said. Enterprise transformation is different. It’s a huge task and it is the actual end. Enterprise Architecture is a profession that can help lead the transformation successfully.

Almost everybody in the enterprise is engaged in [transformation] one way or another. The enterprise architect plays more like a facilitator role. They are bringing the folks together, aligning them with the transformation, the vision of it, and then driving the transformation and building the capabilities. Those are the roles I will look at EA handling, but definitely, these two are two different aspects.

Gardner: Is there something about the state of affairs right now that makes Enterprise Architecture specifically important or particularly important for enterprise transformation?

Naidu: We know many organizations that have successfully transformed without really calling a function EA and without really using help from a team called EA. But indirectly they are using the same processes, methods, and best practices. They may not be calling those things out, but they are using the best practices.

Rouse: There are two distinctions I’d like to draw. First of all, in the many transformation experiences we’ve studied, you can simplistically say there are three key issues: people, organizations, and technology, and the technology is the easy part. The people and organizations are the hard part.

The other thing is I think you’re talking about is the enterprise IT architecture. If I draw an Enterprise Architecture, I actually map out organizations and relationships among organizations and work and how it gets done by people and view that as the architecture of the enterprise.

Important enabler

Sometimes, we think of an enterprise quite broadly, like the architecture of the healthcare enterprise is not synonymous with information technology (IT). In fact, if you were to magically overnight have a wonderful IT architecture throughout our healthcare system in United States, it would be quite helpful but we would still have a problem with our system because the incentives aren’t right. The whole incentive system is messed up.

So I do think that the enterprise IT architecture, is an important enabler, a crucial enabler, to many aspects of enterprise transformation. But I don’t see them as close at all in terms of thinking of them as synonymous.

Gardner: Len Fehskens, are we actually talking about IT architecture or Enterprise Architecture and what’s the key difference?

Fehskens: Well, again that’s this part of the problem, and there’s a big debate going on within the Enterprise Architecture community whether Enterprise Architecture is really about IT, in which case it probably ought to be called enterprise IT architecture or whether it’s about the enterprise as a whole.

For example, when you look at the commitment of resources to the IT function in most organizations, depending on how you count, whether you count by headcount or dollars invested or whatever, the numbers typically run about 5-10 percent. So there’s 90 percent of most organizations that is not about IT, and in the true enterprise transformation, that other 90 percent has to transform itself as well.

So part of it is just glib naming of the discipline. Certainly, what most people mean when they say Enterprise Architecture and what is actually practiced under the rubric of Enterprise Architecture is mostly about IT. That is, the implementation of the architecture, the effects of the architecture occurs primarily in the IT domain.

Gardner: But, Len, don’t TOGAF® at The Open Group and ArchiMate really step far beyond IT? Isn’t that sort of the trend?

Fehskens: It certainly is a trend, but I think we’ve still got a long way to go. Just look at the language that’s used in the architecture development method (ADM) for TOGAF, for example, and the model of an Enterprise Architecture. There’s business, information, application, and technology.

Well, three of those concepts are very much related to IT and only one of them is really about business. And mostly, the business part is about that part of the business that IT can provide support for. Yes, we do know organizations that are using TOGAF to do architecture outside of the IT realm, but the way it’s described, the way it was originally intended, is largely focused on IT.

Not a lot going on

What is going on is generally not called architecture. It’s called organizational design or management or it goes under a whole bunch of other stuff. And it’s not referred to as Enterprise Architecture, but there is a lot of that stuff happening. As I said earlier, it is essential to making enterprise transformation successful.

My personal opinion is that virtually all forms of design involve doing some architectural thinking. Whether you call it that or not, architecture is a particular aspect of the design process, and people do it without recognizing it, and therefore are probably not doing it explicitly.

But Bill made a really important observation, which is that it can’t be solely about IT. There’s lots of other stuff in the enterprise that needs to transform.

Ross: Go back to the challenge we have here of Enterprise Architecture being buried in the IT unit. Enterprise Architecture is an enterprise effort, initiative, and impact. Because Enterprise Architecture is so often buried in IT, IT people are trying to do things and accomplish things that cannot be done within IT.

We’ve got to continue to push that Enterprise Architecture is about designing the way this company will do it business, and that it’s far beyond the scope of IT alone. I take it back to the transformation discussion. What we find is that when a company really understands Enterprise Architecture and embraces it, it will go through a transformation, because it’s not used to thinking that way and it’s not used to acting that way.

Disciplined processes

If management says we’re going to start using IT strategically, we’re going to start designing ourselves so that we have disciplined business processes and that we use data well. The company is embracing Enterprise Architecture and that will lead to a transformation.

Gardner: You said that someday CIOs are going to report to the enterprise architects, and that’s the way it ought to be. Does that get closer to this notion that IT can’t do this alone, that a different level of thinking across disciplines and functions needs to occur?

Ross: I certainly think so. Look at companies that have really embraced and gotten benefits from Enterprise Architecture like Procter & Gamble, Tetra Pak, and Maersk. At P&G’s, IT is reporting to the CIO but he is also the President of Shared Services. At Maersk and Tetra Pak, it’s the Head of Global Business Processes.

Once we get CIOs either in charge with more of a business role and they are in charge of process, and of the technology, or are reporting to a COO or head of business process, head of business transformation, or head of shared services, then we know what it is we’re architecting, and the whole organization is designed so that architecture is a critical element.

I don’t think that title-wise, this is ever going to happen. I don’t think we’re ever going to see a CIO report to chief enterprise architect. But in practice, what we’re seeing is more CIOs reporting to someone who is, in fact, in charge of designing the architecture of the organization.

By that, I mean business processes and its use of data. When we get there, first of all, we will transform to get to that point and secondly, we’ll really start seeing some benefits and real strategic impact of Enterprise Architecture.

Gardner: There’s some cynicism and skepticism around architecture, and yet, what we’re hearing is it’s not in name only. It is important, and it’s increasingly important, even at higher and higher abstractions in the organization.

How to evangelize?

How then do you evangelize or propel architectural thinking into companies? How do you get the thinking around an architectural approach more deeply engrained in these companies?

Fehskens: Dana, I think that’s the $64,000 question. The fundamental way to get architectural thinking accepted is to demonstrate value. I mean to show that it really brings something to the party. That’s part of my concern about the conflation of enterprise transformation with Enterprise Architecture and making even bigger promises that probably can’t be kept.

The reason that in organizations who’ve tried Enterprise Architecture and decided that it didn’t taste good, it was because the effort didn’t actually deliver any value.

The way to get architectural thinking integrated into an organization is to use it in places where it can deliver obvious, readily apparent value in the short-term and then grow out from that nucleus. Trying to bite off more than you can chew only results in you choking. That’s the big problem we’ve had historically.

It’s about making promises that you can actually keep. Once you’ve done that, and done that consistently and repeatedly, then people will say that there’s really something to this. There’s some reason why these guys are actually delivering on a big promise.

Rouse: We ran a study recently about what competencies you need to transform an organization based on a series of successful case studies and we did a survey with hundreds of top executives in the industry.

The number one and two things you need are the top leader has to have a vision of where you’re going and they have to be committed to making that happen. Without those two things, it seldom happens at all. From that perspective, I’d argue that the CIO probably already does report to the chief architect. Bill Gates and Steve Jobs architected Microsoft and Apple. Carnegie and Rockefeller architected the steel and oil industries.

If you look at the business histories of people with these very successful companies, often they had a really keen architectural sense of what the pieces were and how they needed to fit together. So if we’re going to really be in the transformation business with TOGAF and stuff, we need to be talking to the CEO, not the CIO.

Corporate strategy

Ross: I totally agree. The industries and companies that you cited, Bill, instinctively did what every company is going to need to do in the digital economy, which is think about corporate strategy not just in terms of what products do we offer, what markets are we in, what companies do we acquire, and what things do we sell up.

At the highest level, we have to get our arms around it. Success is dependent on understanding how we are fundamentally going to operate. A lot of CEOs have deferred that responsibility to others and when that mandate is not clear, it gets very murky.

What does happen in a lot of companies, because CEOs have a lot of things to pay attention to, is that once they have stated the very high-level vision, they absolutely can put a head of business process or a head of shared services or a COO type in charge of providing the clarification, providing the day-to-day oversight, establishing the relationships in the organizations so everybody really understands how this vision is going to work. I totally agree that this goes nowhere if the CEO isn’t at least responsible for a very high-level vision.

Gardner: So if what I think I’m hearing is correct, how you do things is just as important as what you do. Because we’re in such a dynamic environment, when it comes to supply chains and communications and the way in which technology influences more and more aspects of business, it needs to be architected, rather than be left to a fiat or a linear or older organizational functioning.

So Bill Rouse, the COO, the chief operating officer, wouldn’t this person be perhaps more aligned with Enterprise Architecture in the way that we’re discussing?

Rouse: Let’s start with the basic data. We can’t find a single instance of a major enterprise transformation in a major company happening successfully without total commitment of top leadership. Organizations just don’t spontaneously transform on their own.

A lot of the ideas and a lot of the insights can come from elsewhere in the organization, but, given that the CEO is totally committed to making this happen, certainly the COO can play a crucial role in how it’s then pursued, and the COO of course will be keenly aware of a whole notion of processes and the need to understand processes.

One of the companies I work very closely with tried to merge three companies by putting inERP. After $300 million, they walked away from the investment, because they realized they had no idea of what the processes were. So the COO is a critical function here.

Just to go back to original point, you want total commitment by the CEO. You can’t just launch the visionary message and walk away. At the same time, you need people who are actually dealing with the business processes to do a lot of the work.

Gardner: What the is the proper relationship between Enterprise Architecture and enterprise transformation?

Ross: I’d say the relationship between Enterprise Architecture and enterprise transformation is two-way. If an organization feels the need for a transformation — in other words, if it feels it needs to do something — it will absolutely need Enterprise Architecture as one of the tools for accomplishing that.

It will provide the clarity the organization needs in a time of mass change. People need to know where they’re headed, and that is true in how they do their processes, how they design their data, and then how they implement IT.

It works just as well in reverse. If a company hasn’t had a clear vision of how they want to operate, then they might introduce architecture to provide some of that discipline and clarity and it will inevitably lead to a transformation. When you go from just doing what every individual thought was best or every business unit thought was best to an enterprise vision of how a company will operate, you’re imposing a transformation. So I think we are going to see these two hand-in-hand.

What’s the relationship?

Rouse: I think enterprise transformation often involves a significant fundamental change of the Enterprise Architecture, broadly defined, which can then be enabled by the enterprise IT architecture.

Naidu: Like I mentioned in the beginning, one is end, another one is means. I look at the enterprise transformation as an end and Enterprise Architecture providing the kind of means. In one way it’s like reaching the destination using some kind of transportation mechanism. That’s how I look at the difference between EA and ET.

Fehskens: One of the fundamental principles of architecture is taking advantage of reuse when it’s appropriate. So I’m just going to reuse what everybody just said. I can’t say it better. Enterprise Architecture is a powerful tool for effecting enterprise transformation.

Jeanne is right. It’s a symmetric or bidirectional back-and-forth kind of relationship.

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 Conference, Enterprise Architecture, Enterprise Transformation

Tagged as , , , , , , , , , , ,

by | February 14, 2012 · 11:15 AM

Architecture and Change

By Leonard Fehskens, The Open Group

The enterprise transformation theme of The Open Group’s San Francisco conference reminded me of the common assertion that architecture is about change, and the implication that Enterprise Architecture is thus about enterprise transformation.

We have to be careful that we don’t make change an end in itself. We have to remember that change is a means to the end of getting something we want that is different from what we have. In the enterprise context, that something has been labeled in different ways. One is “alignment”, specifically “business/IT alignment.” Some have concluded that alignment isn’t quite the right idea, and it’s really “integration” we are pursuing. Others have suggested that “coherency” is a better characterization of what we want.

I think all of these are still just means to an end, and that end is fitness for purpose. The pragmatist in me says I don’t really care if all the parts of a system are “aligned” or “integrated” or “coherent”, as long as that system is fit for purpose, i.e., does what it’s supposed to do.

I’m sure some will argue that alignment and integration and coherency ensure that a system is “optimal” or “efficient”, but doing the wrong thing optimally or efficiently isn’t what we want systems to do. It’s easy to imagine a system that is aligned, integrated and coherent but still not fit for purpose, and it’s just as easy to imagine a system that is not aligned, not integrated and not coherent but that is fit for purpose. Of course, we can insist that alignment, integration and coherency be with respect to a system’s purpose, but if that’s the case, why don’t we say so directly? Why use words that strongly suggest internal properties of the system rather than its relationship to an external purpose?

Whatever we call it, continuous pursuit of something is ultimately the continuous failure to achieve it. It isn’t the chase that matters, it’s the catch. While I am sympathetic to the idea that there is intrinsic value in “doing architecture,” the real value is in the resulting architecture and its implementation. Until we actually implement the architecture, we can only answer the question, “Are we there yet?” with, “No, not yet”.

Let me be clear that I’m not arguing, or even assuming, that things don’t change and we don’t need to cope with change.  Of course they do, and of course we do. But we should take a cue from rock climbers – the ones who don’t fall generally follow the principle “only move one limb at a time, from a secure position.” What stakeholders mean by fitness for purpose must be periodically revisited and revised. It’s fashionable to say “Enterprise Architecture is a journey, not a destination,” and this is reflected in definitions of Enterprise Architecture that refer to it as a “continuous process.” However, the fact is that journey has to pass through specific waypoints. There may be no final destination, but there is always a next destination.

Finally, we should not forget that while the pursuit of fitness for purpose may require that some things change; it may also require that some things not change. We risk losing this insight if we conclude that the primary purpose of architecture is to enable change. The primary purpose of architecture is to ensure fitness for purpose.

For a fuller treatment of the connection between architecture and fitness for purpose, see my presentations to The Open Group Conferences in Boston, July 2010, “What ‘Architecture’ in ‘Enterprise Architecture’ Ought to Mean,” and Amsterdam, October 2010, “Deriving Execution from Strategy: Architecture and the Enterprise.”

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.

19 Comments

Filed under Enterprise Architecture, Enterprise Transformation

Tagged as , , , ,

by | February 6, 2012 · 12:30 AM

San Francisco Conference Observations: Enterprise Transformation, Enterprise Architecture, SOA and a Splash of Cloud Computing

By Chris Harding, The Open Group 

This week I have been at The Open Group conference in San Francisco. The theme was Enterprise Transformation which, in simple terms means changing how your business works to take advantage of the latest developments in IT.

Evidence of these developments is all around. I took a break and went for coffee and a sandwich, to a little cafe down on Pine and Leavenworth that seemed to be run by and for the Millennium generation. True to type, my server pulled out a cellphone with a device attached through which I swiped my credit card; an app read my screen-scrawled signature and the transaction was complete.

Then dinner. We spoke to the hotel concierge, she tapped a few keys on her terminal and, hey presto, we had a window table at a restaurant on Fisherman’s Wharf. No lengthy phone negotiations with the Maitre d’. We were just connected with the resource that we needed, quickly and efficiently.

The power of ubiquitous technology to transform the enterprise was the theme of the inspirational plenary presentation given by Andy Mulholland, Global CTO at Capgemini. Mobility, the Cloud, and big data are the three powerful technical forces that must be harnessed by the architect to move the business to smarter operation and new markets.

Jeanne Ross of the MIT Sloan School of Management shared her recipe for architecting business success, with examples drawn from several major companies. Indomitable and inimitable, she always challenges her audience to think through the issues. This time we responded with, “Don’t small companies need architecture too?” Of course they do, was the answer, but the architecture of a big corporation is very different from that of a corner cafe.

Corporations don’t come much bigger than Nissan. Celso Guiotoko, Corporate VP and CIO at the Nissan Motor Company, told us how Nissan are using enterprise architecture for business transformation. Highlights included the concept of information capitalization, the rationalization of the application portfolio through SOA and reusable services, and the delivery of technology resource through a private cloud platform.

The set of stimulating plenary presentations on the first day of the conference was completed by Lauren States, VP and CTO Cloud Computing and Growth Initiatives at IBM. Everyone now expects business results from technical change, and there is huge pressure on the people involved to deliver results that meet these expectations. IT enablement is one part of the answer, but it must be matched by business process excellence and values-based culture for real productivity and growth.

My role in The Open Group is to support our work on Cloud Computing and SOA, and these activities took all my attention after the initial plenary. If you had, thought five years ago, that no technical trend could possibly generate more interest and excitement than SOA, Cloud Computing would now be proving you wrong.

But interest in SOA continues, and we had a SOA stream including presentations of forward thinking on how to use SOA to deliver agility, and on SOA governance, as well as presentations describing and explaining the use of key Open Group SOA standards and guides: the Service Integration Maturity Model (OSIMM), the SOA Reference Architecture, and the Guide to using TOGAF for SOA.

We then moved into the Cloud, with a presentation by Mike Walker of Microsoft on why Enterprise Architecture must lead Cloud strategy and planning. The “why” was followed by the “how”: Zapthink’s Jason Bloomberg described Representational State Transfer (REST), which many now see as a key foundational principle for Cloud architecture. But perhaps it is not the only principle; a later presentation suggested a three-tier approach with the client tier, including mobile devices, accessing RESTful information resources through a middle tier of agents that compose resources and carry out transactions (ACT).

In the evening we had a CloudCamp, hosted by The Open Group and conducted as a separate event by the CloudCamp organization. The original CloudCamp concept was of an “unconference” where early adopters of Cloud Computing technologies exchange ideas. Its founder, Dave Nielsen, is now planning to set up a demo center where those adopters can experiment with setting up private clouds. This transition from idea to experiment reflects the changing status of mainstream cloud adoption.

The public conference streams were followed by a meeting of the Open Group Cloud Computing Work Group. This is currently pursuing nine separate projects to develop standards and guidance for architects using cloud computing. The meeting in San Francisco focused on one of these – the Cloud Computing Reference Architecture. It compared submissions from five companies, also taking into account ongoing work at the U.S. National Institute of Standards and Technology (NIST), with the aim of creating a base from which to create an Open Group reference architecture for Cloud Computing. This gave a productive finish to a busy week of information gathering and discussion.

Ralph Hitz of Visana, a health insurance company based in Switzerland, made an interesting comment on our reference architecture discussion. He remarked that we were not seeking to change or evolve the NIST service and deployment models. This may seem boring, but it is true, and it is right. Cloud Computing is now where the automobile was in 1920. We are pretty much agreed that it will have four wheels and be powered by gasoline. The business and economic impact is yet to come.

So now I’m on my way to the airport for the flight home. I checked in online, and my boarding pass is on my cellphone. Big companies, as well as small ones, now routinely use mobile technology, and my airline has a frequent-flyer app. It’s just a shame that they can’t manage a decent cup of coffee.

Dr. Chris Harding is Director for Interoperability and SOA at The Open Group. He has been with The Open Group for more than ten years, and is currently responsible for managing and supporting its work on interoperability, including SOA and interoperability aspects of Cloud Computing. Before joining The Open Group, he was a consultant, and a designer and development manager of communications software. With a PhD in mathematical logic, he welcomes the current upsurge of interest in semantic technology, and the opportunity to apply logical theory to practical use. He has presented at Open Group and other conferences on a range of topics, and contributes articles to on-line journals. He is a member of the BCS, the IEEE, and the AOGEA, and is a certified TOGAF practitioner.

Leave a Comment

Filed under Cloud, Cloud/SOA, Conference, Enterprise Architecture, Enterprise Transformation, Service Oriented Architecture, Standards

Tagged as , , , , , , , , , , , , , , , , , , ,

by | February 2, 2012 · 3:00 PM

Setting Expectations and Working within Existing Structures the Dominate Themes for Day 3 of San Francisco Conference

By The Open Group Conference Team

Yesterday concluded The Open Group Conference San Francisco. Key themes that stood out on Day 3, as well as throughout the conference, included the need for a better understanding of business expectations and existing structures.

Jason Bloomberg, president of ZapThink, began his presentation by using an illustration of a plate of spaghetti and drawing an analogy to Cloud Computing. He compared spaghetti to legacy applications and displayed the way that enterprises are currently moving to the Cloud – by taking the plate of spaghetti and physically putting it in the Cloud.

A lot of companies that have adopted Cloud Computing have done so without a comprehensive understanding of their current organization and enterprise assets, according to Mr. Bloomberg. A legacy application that is not engineered to operate in the Cloud will not yield the hyped benefits of elasticity and infinite scalability. And Cloud adoption without well thought-out objectives will never reach the vague goals of “better ROI” or “reduced costs.”

Mr. Bloomberg urged the audience to start with the business problem in order to understand what the right adoption will be for your enterprise. He argued that it’s crucial to think about the question “What does your application require?” Do you require Scalability? Elasticity? A private, public or hybrid Cloud? Without knowing a business’s expected outcomes, enterprise architects will be hard pressed to help them achieve their goals.

Understand your environment

Chris Lockhart, consultant at Working Title Management & Technology Consultants, shared his experiences helping a Fortune 25 company with an outdated technology model support Cloud-centric services. Lockhart noted that for many large companies, Cloud has been the fix-it solution for poorly architected enterprises. But often times after the business tells architects to build a model for cloud adoption, the plan presented and the business expectations do not align.

After working on this project Mr. Lockhart learned that the greatest problem for architects is “people with unset and unmanaged expectations.” After the Enterprise Architecture team realized that they had limited power with their recommendations and strategic roadmaps, they acted as negotiators, often facilitating communication between different departments within the business. This is where architects began to display their true value to the organization, illustrated by the following statement made by a business executive within the organization: “Architects are seen as being balanced and rounded individuals who combine a creative approach with a caring, thoughtful disposition.”

The key takeaways from Mr. Lockhart’s experience were:

  • Recognize the limitations
  • Use the same language
  • Work within existing structures
  • Frameworks and models are important to a certain extent
  • Don’t talk products
  • Leave architectural purity in the ivory tower
  • Don’t dictate – low threat level works better
  • Recognize that EA doesn’t know everything
  • Most of the work was dealing with people, not technology

Understand your Cloud Perspective

Steve Bennett, senior enterprise architect at Oracle, discussed the best way to approach Cloud Computing in his session, entitled “A Pragmatic Approach to Cloud Computing.” While architects understand and create value driven approaches, most customers simply don’t think this way, Mr. Bennett said. Often the business side of the enterprise hears about the revolutionary benefits of the Cloud, but they usually don’t take a pragmatic approach to implementing it.

Mr. Bennett went on to compare two types of Cloud adopters – the “Dilberts” and the “Neos” (from the Matrix). Dilberts often pursue monetary savings when moving to the Cloud and are late adopters, while Neos pursue business agility and can be described as early adopters, again highlighting the importance of understanding who is driving the implementation before architecting a plan.

Leave a Comment

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

Tagged as , , , , , , , , , , , , ,

by | · 1:09 PM

San Francisco Conference Day 2 – Enterprise Transformation: The New Role of Open Standards

By The Open Group Conference Team

The Open Group Conference in San Francisco has brought together a plenary of speakers from across the globe and disciplines. While their perspective on enterprise architecture is different, most seem to agree that enterprise transformation is gaining momentum within the enterprise architecture community. During Day Two of the Conference in San Francisco, a number of speakers continued the discussion and the role that standards play in the process of fundamentally changing the enterprise.

The New Role of Open Standards

Allen Brown, President and CEO of The Open Group set the tone for the day during his opening address, providing an overview of enterprise transformation and the role that enterprise architecture and open standards have in shaping the future.

“It’s a journey, not an event,” stated Brown. He also reinforced that enterprise transformation in not just about reducing costs – it’s about improving capabilities, functionality and communication.

In addition to highlighting the tremendous accomplishments of its over 400 member organizations, Brown showcased a number of case studies from a wide range of global enterprises who are leveraging enterprise architecture (EA). For example:

  • University Health Network in Ontario is utilizing EA as a solution for improving the quality of healthcare without increasing the cost
  • Caja Madrid relies on EA to improve the bank’s capabilities while reducing its vulnerabilities and the cost of those vulnerabilities
  • SASOL, an integrated energy company in South Africa, is utilizing EA to improve the organization’s function while reducing cost
  • Cisco is utilizing EA as it provides a common language for cross functional communication

Brown also mentioned the release of a new open standard from the FACE Consortium, which is transforming the avionics industry. According to Capt. Tracy Barkhimer, program manager for the Air Combat Electronics Program Office (PMA-209), the new standard “is quite possibly the most important innovation in Naval aviation since computers were first incorporated into airplanes. This will truly pave the way for the future.”

An Architecture –based Approach

The next plenary speaker was Bill Rouse, the Executive Director of Tennenbaum Institute at the Georgia Institute of Technology, and a professor in the College of Computing and School of Industrial and Systems Engineering. His research focuses on understanding and managing complex public-private systems such as healthcare, energy and defense, with emphasis on mathematical and computational modeling of these systems for the purpose of policy design and analysis.

Rouse posed the notion: you can be the innovator or the transformer.

Of course all businesses want to be the former. So how is architecture involved? According to Rouse, architectures are transformative by nature by providing evidence-based decision making by looking at an enterprise’s operational systems, technical levels and socio-technical architectures. However, as he pointed out: “You have to being willing to change.”

Building a Roadmap to Solve the Problem

Tim Barnes, Chief Architect at Devon Energy, one of North America’s leading independent producers of oil and natural gas, shared his hands-on experience with enterprise architecture and the keys to the company’s success. After the company experienced a profound growth between 1998 and 2010, the company needed to simplify its system to eliminate berries that were impacting business growth and driving excessive IT costs. Barnes was chartered by Devon to develop an EA discipline for the company and leverage the EA process to reduce unnecessary complexity, help streamline the business and lower IT costs.

The Cyber Threat

Rounding out the lineup of plenary speakers was Joseph Menn, a renowned journalist in the area of cyber security and the author of Fatal System Error: The Hunt for the New Crime Lords Who are Bringing Down the Internet.

When it comes to cybercrime and security, “no one is telling us how bad it really is,” said Menn. After providing a few fear-provoking examples, and instilling that the Stuxnet affair is just a small example of things to come, Menn made it clear that government will only provide a certain level of protection – enterprises must take action to protect themselves and their intellectual property.

Leave a Comment

Filed under Certifications, Cybersecurity, Enterprise Architecture, Enterprise Transformation, FACE™, Standards

Tagged as , , , , , , , , , , ,

by | January 31, 2012 · 9:52 AM

The Open Group San Francisco Conference: Day 1 Highlights

By The Open Group Conference Team

With the end of the first day of the conference, here are a few key takeaways from Monday’s key note sessions:

“The Enterprise Architect: Architecting Business Success”

Jeanne Ross, Director & Principal Research Scientist, MIT Center for Information Systems Research

Ms. Ross began the plenary discussing the impact of enterprise architecture on the whole enterprise. According to Ross “we live in a digital economy, and in order to succeed, we need to excel in enterprise architecture.” She went on to say that the current “plan, build, use” model has led to a lot of application silos. Ms. Ross also mentioned that enablement doesn’t work well; while capabilities are being built, they are grossly underutilized within most organizations.

Enterprise architects need to think about what capabilities their firms will exploit – both in the short- and long-terms. Ms. Ross went on to present case studies from Aetna, Protection 1, USAA, Pepsi America and Commonwealth of Australia. In each of these examples, architects provided the following business value:

  • Helped senior executives clarify business goals
  • Identified architectural capability that can be readily exploited
  • Presented Option and their implications for business goals
  • Built Capabilities incrementally

A well-received quote from Ms. Ross during the Q&A portion of the session was, “Someday, CIOs will report to EA – that’s the way it ought to be!”

“How Enterprise Architecture is Helping Nissan IT Transformation”

Celso Guiotoko, Corporate Vice President and CIO, Nissan Motor Co., Ltd.

Mr. Guiotoko presented the steps that Nissan took to improve the efficiency of its information systems. The company adapted BEST – an IT mid-term plan that helped led enterprise transformation within the organization. BEST was comprised of the following components:

  • Business Alignment
  • Enterprise Architecture
  • Selective Sourcing
  • Technology Simplification

Guided by BEST and led by strong Enterprise Architecture, Nissan saw the following results:

  • Reduced cost per user from 1.09 to 0.63
  • 230,000 return with 404 applications reduced
  • Improved solution deployment time
  • Significantly reduced hardware costs

Nissan recently created the next IT mid-term plan called “VITESSE,” which stands for value information, technology, simplification and service excellence. Mr. Guiotoko said that VITESSE will help the company achieve its IT and business goals as it moves toward the production of zero-emissions vehicles.

“The Transformed Enterprise”

Andy Mulholland, Global CTO, Capgemini

Mr. Mulholland began the presentation by discussing what parts of technology comprise today’s enterprise and asking the question, “What needs to be done to integrate these together?” Enterprise technology is changing rapidly and  the consumerization of IT only increasing. Mr. Mulholland presented a statistic from Gartner predicting that up to 35 percent of enterprise IT expenditures will be managed outside of the IT department’s budget by 2015. He then referenced the PC revolution when enterprises were too slow to adapt to employees needs and adoption of technology.

There are three core technology clusters and standards that are emerging today in the form of Cloud, mobility and big data, but there are no business process standards to govern them. In order to not repeat the same mistakes of the PC revolution, organizations need to move from an inside-out model to an outside-in model – looking at the activities and problems within the enterprise then looking outward versus looking at those problems from the outside in. Outside-in, Mulholland argued, will increase productivity and lead to innovative business models, ultimately enabling your enterprise to keep up the current technology trends.

“Making Business Drive IT Transformation through Enterprise Architecture”

Lauren States, VP & CTO of Cloud Computing and Growth Initiatives, IBM Corp.

Ms. States began her presentation by describing today’s enterprise – flat, transparent and collaborative. In order to empower this emerging type of enterprise, she argued that CEOs need to consider data a strategic initiative.

Giving the example of the CMO within the enterprise to reflect how changing technologies affect their role, she stated, “CMOS are overwhelming underprepared for the data explosion and recognize a need to invest in and integrate technology and analytics.” CIOs and architects need to use business goals and strategy to set the expectation of IT. Ms. States also said that organizations need to focus on enabling growth, productivity and cultural change – factors are all related and lead to enterprise transformation.

*********

The conference will continue tomorrow with overarching themes that include enterprise transformation, security and SOA. For more information about the conference, please go here: http://www3.opengroup.org/sanfrancisco2012

Leave a Comment

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

Tagged as , , , , , , , , , , , , , , , ,