#eavoices

Schism and doubt

by

On Friday 14th June, there was a public meeting of the EAST group, entitled Perspectives on Enterprise Architecture and Systems Thinking, kindly hosted by BT in its offices near St Paul’s. Tom Graves has posted a detailed write-up on his blog At ‘EA and Systems-Thinking’ conference.

What is the purpose of dialogue between EA and ST? Putting aside the debate about what the labels “Enterprise Architecture” and “Systems Thinking” might mean, there is certainly a thought that the two (or more) communities can learn from each other. There are strengths and weaknesses on both sides – so we may be able to produce a critique of EA from an ST perspective, or a critique of ST from an EA perspective. For example, in his presentation, John Holland asserted that “EA is broken – How ST can help”. (See Tom’s blog for summary.)

This kind of material often arouses a certain kind of resistance. “He’s not talking about me, he must be talking about someone else.” Where are the EAs to whom such a criticism as John’s might apply? Surely the fact that we are going to these meetings, or reading these blogs, or participating in these Linked-In discussions, puts us into the most sophisticated and reflective quartile? 

One of the fundamental questions underlying discussion of EA and ST is imagining some kind of landscape with more or less distinct zones: EA over here, ST over there, this or that school of EA, this or that school of ST, good EA versus bad EA, authentic ST versus fake ST, mainstream versus next practice.

I have written several pieces on the relationship between Enterprise Architecture (EA) and Systems Thinking (ST), on this blog and elsewhere, but such pieces are always open to challenge by those who disagree about the correct use of the labels.

  • “That’s not what real Enterprise Architects do.”
  • “That’s not really Systems Thinking.”

So it sometimes seems that we cannot even start talking about EA and ST, and about the relationship (if any) between them, until we can agree what these terms mean. The desire to name things properly is an ancient one, and can be found in the Analects of Confucius. (See my post on the Wisdom of Confucius). But the prevailing desire to impose one’s own definitions leads to endless and mostly unproductive debate on Linked-In and elsewhere. For this meeting, we hoped for a more productive energy, and I like to think we largely succeeded.

Some of the speakers fell into a dialectic mode of presentation – on the one hand EA, on the other hand ST. This can be useful as a starting point, but if the distinction between EA and ST is taken too seriously it may drive a wedge between practitioners. As Tom commented, “there don’t seem to be any clear distinctions, any absolute boundaries that determine who’s ‘in’ and who’s ‘out’ – all a bit blurry all round, really.” For my part, instead of trying to avoid making any distinctions whatsoever, I put up a few slides with some provocative and playful distinctions, flagged with “possibly” and “tongue-in-cheek”. But I haven’t always been consistent about this, and (as someone pointed out to me) I probably need to be more careful when making a rhetorical contrast between “mainstream” and “next practice”.

The EA/ST landscape may include Confucian and dialectic modes, but it should also include Daoist and dialogic modes. (For a brief explanation of the difference between dialectic and dialogic, see Wikipedia: Dialogic.) Robust debate between dogmatic EA and dogmatic ST may lead to schism, but even that is preferable to bland and empty speech. If we want to have a serious discussion about the strengths and weaknesses of current practice, then we must be prepared for robust critique, and we should not have to worry about over-sensitive practitioners taking everything personally.

One possible aspiration is to build a bridge between two communities, or perhaps even one single community. In their presentation, Patrick Hoverstadt and Lucy Loh presented some recent work of the EAST working group, showing how the concepts and techniques of EA and ST could be combined to address business challenges. This work is ongoing.
If we take the view that community building depend on affiliation (finding common beliefs and values), then any schism and doubt may seem to undermine this agenda. However, there is a more robust path to community building, based on alliance (accepting and overcoming difference for the sake of collaboration). For an eloquent defence of what she calls Deep Disagreement, see Margaret Heffernan’s TED Talk Dare to Disagree.

Perhaps some people will think me perverse, but I look forward to plenty more friendly disagreement between EA and ST in future.

The Chief Marketing Technology Officer – CMTO – and the EA

by

Admittedly, it’s a bit of a leap – addressing the converging roles of the CIO and CMO (Chief Marketing Officer) with an Enterprise Architecture perspective, particularly when a CMO’s “Enterprise” ranges far and wide of the actual organization they serve. The Internet does extend now into outer space a bit, after all.

The classic scope of the Enterprise is that which is contained within both an operating and investment budget (OPEX and CAPEX) – the assets and resources that are produced, consumed and used under a common business (or mission) strategy.  Perhaps a company or agency, a department or line-of-business, or some other facility or organization segment. Enterprise Architects (EAs) most often influence these sorts of enterprise contexts.

A CMO certainly runs a business segment, investing in people, assets and consumable resources – most of which can be touched, inventoried or governed in some way to align with the segment’s business strategy (make revenue, deliver goods or services, be a public steward, contain costs, mitigate risk). A CMO’s “Enterprise”, particularly in this digital age, is also that of the online, networked audience. Social media profiles, data feed providers, branded communications channels, publisher networks and web app platforms – these also are part of the CMO’s “Enterprise”, and require some degree of monitoring, governance, investment control, integrated standardization.  Digital marketing campaign assets and advertisements aren’t usually just thrown to the wilds of the Interwebs (unless they are) – they’re carefully planned, tested, optimized, controlled, monitored and analyzed – both their original forms and any derivations.

Note that, for purposes of this blog, the “CMO” is readily compared to the “Government Services PR Lead” or “Constituent Relationship Communications Lead” – or basically any other leadership position in charge of outreach, communications and basically marketing of Public Sector capabilities or services.

“Traditional” EA doesn’t seem to address the Internet of things, stuff and services as something to be modeled, or deemed compliant, or aligned with standard reference frameworks. This isn’t unlike trying to apply one EA’s influence across an SOA interface boundary – while there are certainly very useful, open standards for both to leverage in delivering SOA success, one organization’s EA model compliance and content isn’t necessarily usable or useful to another organization.  

Can or should one’s Enterprise Architecture scope and framework be applied to all those 3rd-party Internet-hosted products and services a CMO relies upon?  Why not – particularly if this “External Interactive Marketing” business domain is scoped according to some kind of “services taxonomy” (that may likely have parallel definition back within the organization).  For example “Data Publishing” services (like Equifax), “Search” services (like Google), “Information Sharing” and “Community Management” services (like Facebook and LinkedIn).  While these Internet capabilities aren’t owned by the organization, how they’re used can certainly be modeled and approached from the same architectural principles, standards and experience as a already found within the organization.

Enter the “Chief Marketing Technology Officer” (CMTO), a role that combines digital marketing practice and Internet services technology knowledge, with the classic IT investment, management and operations knowledge of a CIO (or CTO). The CMTO not only understands what’s necessary to secure and control information within his organization, but also understands what does or can happen to this information on the public Internet – planned or not.  
Below is a proposed standard “Domain Reference Architecture” for the CMTO role, depicting also the intersection (and expansion) of the traditional EA role.

Chief Marketing Technology Officer Domain Reference Architecture

Helping the CMTO apply architectural principles, governance and repeatable methods for the information lifecycle external to the organization – that’s a worthwhile and appropriate role for the Enterprise Architect…and may be all the more relevant as programs and lines-of-business holistically outsource their information management capabilities to 3rd-party providers and cloud services.  Full-scope alignment of the EA practice to the CMO/CMTO’s domain is probably inevitable, as more industry analysts point to the rapid and dominant global enterprise demand of marketing departments on their organization’s IT investment portfolio.

As written on the Oracle Social Spotlight Blog, “CMOs must see the science behind the art. CIOs must see the art behind the science”.  EAs must align the art and science to meet the business case.

The Big 8 Business Objectives

by

Welcome to financial year 2014! Whew! July marks the new financial year and for some of us, the end of a strategy, planning and budgeting cycle. Once again, I had the opportunity to design and facilitate my organization’s business strategy, planning and budgeting process and it seems that each time I learn tons. As a…

6 IT Trends & 15 New Habits for CIOs & Their Teams

by

The CIO/ITD In Crisis.

Harvard Business Review blogger, Jim Stikeleather, posted recently  The CIO in Crisis: What You Told Us – a few particular points caught my attention:

“The best executives I have met have had a great understanding of how to use technology to gain competitive advantage and improve operations. They also worked with the CIO to help them to understand the business. They worked together to identify the technologies that could improve the company’s competitive advantage versus technologies that were needed to support the business. Once this was done, the executive leadership and CIO focused on implementing technologies that improve the company’s competitive advantage”.

“All the parts of the organization have to come together and build a common language to discuss their markets and their enterprise. They need to have a common appreciation of each other’s purpose. The CIO must step up and mentor the C-suite on the potentials, possibilities, threats and opportunities of information technology..”.

“If IT and the CIO come to the party talking like engineers, only offer convergent lines of thought(analytical, rational, quantitative, sequential, constraint driven, objective and detailed focus) and don’t offer a more holistic, shaded divergent thinking point of view (creative, intuitive, qualitative, subjective, possibility driven, holistic with conceptual abstractions), then they have missed the point”.

“The CEOs were actively aware, concerned, looking at alternatives such as chief digital officers, or creating “not-so-shadow” IT organizations under the CMO”.
“For existing CIOs, ask yourself a few questions. Are you generating customer value? Are you (or do you have the potential to be) the best in the world at what you are doing? Are you required to do what you are doing? Using the answers to those questions, what do you need to stop doing, start doing or do differently?..”. [see 15 ways to change the ITD’s habits table later in this post].

In a similar vein, according to a recent CIO event run by Forrester Research: “The IT department of 2020 could disappear as a separate entity and become embedded in departments throughout the entire organization“.
This article posits that the need for change is now undeniable, and that CIOs are looking for practical steps for creating new habits in their teams. These new habits, developed now, will help prove the continuing need for a central Enterprise IT Department.


History & Trends.

The demise of the IT Department is not a new  prediction, it was first suggested in 2004 by Nicolas Carr in his book ‘Does IT Matter?‘ and again in 2007 when Chris Anderson published his ‘Black Wire – White Wire’ article. This post talked about how corporate IT was being over-taken by consumer-IT. Later, in January 2008,  Nicholas Carr famously pronounced “The IT department is dead” referring to the up-take of utility computing since his 2004 prediction. 

Since then, others made further observations about emerging IT trends that appear to strengthen those predictions. Today, around six hard trends are well established. They sit within an umbrella trend we described as ‘Externalization’ back in 2007. Later, in ‘Flash Foresight‘ Daniel Burrus explains how he identified many of the established technology trends and why they are ‘Hard’ trends rather than passing fads. More recently,  in his book ‘Agile Architecture Revolution‘, Jason Bloomberg talks about understanding the enterprise as a Complex System – a System-of-Systems. His book is architectural guide to help IT Departments respond to the Externalization trend and, at the same time, it highlights the need for a change in mindset within the IT community.

In parallel, John R. Rymer of Forrester Research coined the phrase ‘Business Technology’ (BT) to describe the ever-increasing reliance on information technology by businesses of all types to handle and optimize their business processes  and the need for a more integrated & holistic approach to the use of business-embedded information technology.  Here’s what Wikipedia says about BT: 

“The increasing use of the term business technology in IT forums and publications is due to an emerging school of thought that the potential of information technology, its industries and experts, has now moved beyond the meaning of the term. Specifically information is seen by some as a descriptor not broad enough to cover the contribution that technology can make to the success of a business or organization“.

Focus on Externalization and BT.


Acceptance of the Externalization trend, and a deep appreciation of ‘Business Technology’ theme, provide the canvas, on which, we can sketch-out the ways in which the IT Department must change to survive. Probably most importantly, the CIO needs to find the time to think strategically: from ‘Whac-A-Mole-IT-Management’  to strategic, Business-Technology leadership. Thinking strategically means the CIO needs to develop a deep appreciation of  the various ‘markets’ his/her team serve, as both a supplier, and a broker of services, to those markets. Such markets exists within and outside the enterprise and are made up of customers, suppliers, intermediaries and other stakeholders. All with differing values and requiring different sensitivities to protect and enhance trust relationships.

How to prepare for the inevitable change.

At my current company, we use the ‘BT’ label help position our five-year vision & strategy. It helps frame the discussion about the many areas of change required: cultural, technological, procedural, organizational & regulatory. BT is not, however, a new name-tag for the IT department – it represents the new thinking required across the whole business. It might seem ironic, given the predictions, that it was our CIO who initiated the discussion – I suspect, however, this will often be the case: the CIO is frequently the only C-level executive who has a holistic understanding of both the breadth and depth of the business.

Back in May this year, I posted about the work we were doing to establish a BT Vision. This has since been developing gradually and is gaining acceptance across the IT senior leadership team, but more importantly, with C-Level executives.

Recently, I was invited to share, with a large multinational conglomerate, some of the more tangible changes we’re implementing  Our vision & journey towards ‘BT’, and our response to the the ‘Externalization‘ trend set the context for the discussion. Here’s the list of ‘contrasting behaviors‘ I shared: 

15 ways to change the IT Department’s habits

Old Habits
 New Habits
1.The department of ‘No’
2.Products focus
3.Internal SLAs
4.IT Strategy
5.Cyber security tooling
6.CAPEX-first mentality
7.Solution-focused technology architecture
8.Product standardized IT portfolio management
9.Governance of large IT projects
10.IT Cost Centre management
11.Internal procedures & methods
12.‘Family’ of IT vendors
13.Gadget-focused innovation
14.Periodic, internally-focused, measurement
15.Technology focus
1.The department of qualified ‘Yes’
2.Services focus
3.Services internal/external ecosystem –SLA-chains
4.Integrated BT strategy
5.Cyber security culture
6.Balanced, outcome-focused, investment
7.Adaptive, value-focused,  Enterprise Architecture
8.Principle-led architecture & standards-based integration
9.Company-wide, joined-up,  BT-governance
10.BT services broker, innovation-lead and advisory
11.Internal & external engagement
12.Consumer-driven, ecosystem of suppliers
13.Customer-story-based innovation
14.Constant, external & internal, feedback-loops
15.Focus on information value & risk

We’ve made good progress on many of the 15 points, but I’d say the most compelling for the business are: 1) The department of qualified ‘Yes’,  4) Integrated BT strategy, 5) Cyber security culture, and 13) Customer-story-based-innovation. I’m pleased to see these seem resonate with the observations made in the HBR article mentioned above.


Will the IT department will be dead by 2020?

Will the need for a central IT department go away by 2020? No, not in our case at least, but it does need to rapidly adapt and evolve and  we believe those  that don’t will become side-lined. We are seeing, however, other businesses taking a different view: there does seem to a dangerous, frustration-with-the-ITD, pattern emerging where IT departments are being split-up into LOB sub-teams, without considering the need for, holistic, enterprise-wide thinking.

Maybe the IT Department label won’t exist by 2020, but many organizations will require a team that focus on the value of the digitally enabled world that balances agility, resilience, security and cost across the whole enterprise. For these companies, dispersed and unbridled IT (use of consumer-led technologies and commoditized services) would lead to unprecedented levels business risk: operational, financial, commercial, reputational and regulatory. [post addendum: FUD alert! See my response to Nick Gall’s comment].

My hunch is that, once the hype has died down, the Externalization trend will actually strengthen the need for strategic, less operationally-focused, ‘Office of the CIO’ within organizations. I’m sure, however, such an entity will be unlike today’s ‘Operationally-focused’ IT shop, by 2020.

Addendum

Since posting, I was asked where VPEC-T fits in the context of the move towards BT. VPEC-T is a tool for the sense-making of complex systems-of-systems. It deals with the complexities of plurality (e.g.multiple value systems and multiple types of event). Moreover, it is used for sharing stories about such systems which helps: reach common understanding, ensure completeness and make trust explicit. These considerations will be increasingly important in the diverse and emergent world of BT. It’s most applicable to ‘New Habits’ 5,7 & 12-15.
Here’s an example of the preparation for a VPEC-T workshop based on a real session I ran earlier this year – it might help explain plurality need.

What is culture and how does it affect the practice of Enterprise Architecture?

by

As Architects we often spend countless hours working toward delivering great artifacts, including a future state, current state and roadmap to assist our customers in developing a vision and plan toward transformation or maturity. This work is often completed and finds its place on the CIO’s bookshelf or the Lead Architect’s desk with little action or even a second look. Why is this work not actively embraced by many organizations beyond the IT walls or even within the IT organization?

Don’t misunderstand my position, I believe all of the work completed during an iterative EA process that outputs the artifacts I mentioned above add value, although if the organization is not “culturally” ready to embrace the work and transform then the effort is for not.

Culture is defined in many ways by many scholars, although I find it easiest to define culture as interactions and relationships between members of an organization or unit within that organization. This assumes there is an organizational culture and sub cultures within that organization. With this said, it is important that we as architects focus on the overarching organizational culture to better understand whether our customers are ready for an EA engagement.

Our first priority is to ensure we are engaged with the highest level of sponsorship within the organization. For instance, developing physical architectures with the platform division does not constitute Enterprise Architecture, but rather a Technical Architecture and will only have an effect on that sub culture within the organization. EAs need to ensure they are seated alongside the CIO, CFO, COO or even the Chief Executive to ensure efforts toward cultural transformation can be enabled via strong sponsorship.

In the public sector this can be a difficult task as most executives are focused on business related practices and often see the CIO and vendors as “IT focused.” It is critical for our communication during initial contact to be business focused. Conversations about technology are not held until key items, like capability modeling, guiding principles and governance structures are embraced by the organization as a result of cultural change. Once these cultural elements are embraced and socialized technology decisions will be easily facilitated with little debate or power struggles. Remember, the “sponsor” understands how important organizational transformation is at this point in the evolution and will help sub groups understand the vision. Communication and vision are critical elements at this point in the journey toward transformation.

Once we have commitment from the sponsor it is critical for the sponsor to understand the partnership needed between the EA Team and Executive Team. The EA Team is not chartered with creating mission, vision, strategy etc. but rather with understanding the Executive Team’s goals and objectives for the organization and aligning the technology investments with these goals and objectives. Every investment decision made is a direct representation of how the organization’s culture is manifesting itself physically.

Enterprise Architecture Leaders’ Interview Series – Q&A with Gil Long

by
Enterprise Architecture Leaders’ Interview Series – Q&A with Gil Long

I caught up with Gil Long who has served IBM as a Business Development Executive, Distinguished Engineer and CIO Office Chief Enterprise Architecture leader. As the Worldwide Enterprise Architecture Community Leader, he specialized in architecture governance, strategic architecture design and infrastructure transition planning. He was responsible for IBM’s enterprise architecture strategy and planning service offerings, global enterprise architecture training programs, and functioned as a member of IBM’s Architect Certification Board.

Gil has had direct management responsibility for large IT organizations and staffing, and substantial ongoing budget accountability. His multi-industry experience includes international banking, securities, education, retail, healthcare, insurance, utilities, manufacturing, semi-conductor, airlines, telecommunications and government.

Gil is a competitive aerobatics and commercial pilot.

In many years of your experience across hundreds of customers, what is the fundamental thing that organizations miss about Enterprise Architecture?
Understanding the value of EA is often an issue.  The value is not only about reducing IT cost, but investing in innovative ways to improve the business. In my opinion, many companies do not understand what EA is!

EA needs the buy-in from upper management, but most upper managements think it is merely a technical or standards issue, and miss the point that it covers all aspects of business and technical structure and management. It is very important to have someone at the sponsorship level who understands what EA is and what value it brings.

In your experience what has been one of the most remarkable transformations enabled by Enterprise Architecture?
Obviously, I am intimately familiar with IBM’s EA and how it has influenced multiple internal transformations.  I shared with you the IBM Transformation Story. Great showcase!

I have seen many other transformations in the client world.  One involved the consolidation of 90 companies (utilities) into a common footprint!  Generally, the more complex the environment, the greater the benefit EA can deliver.

What do you think is one of the most underrated aspects of Enterprise Architecture? 
The leadership role that an Enterprise Architect can provide to the organization.

For an aspiring Enterprise Architect, what are some key things she needs to start working on right now?
[-] Understand what EA is and what value it brings to the organization.

[-] Get EA training. You could start with understanding TOGAF, which is an internationally recognized standard for Enterprise Architecture.

[-] Get certified if you can, it could establish your credibility both within and outside your organization.

[-] Develop strong relationships with stakeholders that are impacted by EA. Its importance cannot be overstated. Involve them in the process.

[-] Understand your industry. Industries have their own context, business process models, histories, politics and challenges. Understanding your industry gives you an edge when working with partners across the company.

[-] Work on your communication skills. Always put yourself in the shoes of your audience. Communicate in a way that the listener will understand. Your message should be simple, concise and actionable, and answer the question, ‘What’s in it for me?’.

[-] An Enterprise Architect needs to stand up and speak, evangelize ideas, develop consensus, work across boundaries. Do not throw up your hands and quit, or be draconian and say if I don’t get what I want, the world will come to an end!

Do you think Enterprise Architecture has a brand issue?
Yes, the name itself implies it is a technical concept, rather than an overall business concept. The word “architecture” conjures an image of a guy with his head down, drawing a complex picture! The word “enterprise” can also be a bit vague.  The enterprise represents the totality of the business; including business partners, customers and other stakeholders, and the infrastructure they use to accomplish their objectives.

However, a good Enterprise Architect will be able to explain EA to anyone in terms they can understand.

At the risk of drawing you into the “war of EA frameworks”, how important is the EA framework brand to you? 

IBM’s EA Method and Framework are important to me, since IBM ‘invented’ EA in the 1980’s and participated in the internationalization of EA via TOGAF involvement.  All frameworks have something to offer, but they essentially are all true to the same basic EA concepts. 
You should select one EA approach for your enterprise, and TOGAF, the international standard for EA, is generally accepted across all industries worldwide.

You have quite a collection of funny “ditties”! Which one is your favorite?
I have many favorites, but the “You are here!” picture always gets a laugh from architects 🙂

How many countries have you traveled to, for business? Which one was the most unique?
Fifty three countries!  I’ve had so many wonderful experiences in these countries.  Each had its challenges and rewards.  Istanbul (banking) was unique, as was China (telecom), as was Taiwan (semiconductor), and Hawaii (education) … working from the top of a mountain overlooking Pearl Harbor.  Also, Prague, with a mixture of former communist and democratic staff, and South Africa (banking). Although cultures can vary from place to place, I find that the Enterprise Architects are universally smart, enthusiastic and hungry for knowledge about EA.
I smile when I think about nap time on sleeping mats during lunch in China, and loud cell phone conversations going on during a serious lecture!!  What is normal in some countries is unusual in others.
Had to ask this – tell us a little bit about your flying hobby and what are your flying plans for 2013?
Just got back from Sun-n-Fun in Lakeland, Florida (major fly-in with thousands of airplanes).  Next stop is Oshkosh, Wisconsin, the largest fly-in in the US, and possibly the world.  
I practice aerobatics every week and feel quite comfortable being upside down, like any good Enterprise Architect 🙂
I hope you all enjoyed my interview with Gil Long. As usual, please keep your comments and feedback coming, I love to hear from you – whether you agree with me or not! Thank you for reading.

Business Architecture & Enterprise Architecture – Match Made in Heaven

by
I recently spoke at the European BPM and EA Conference in London on this topic. This blog post is a summary version of my session.

Often Business Process Management and associated discipline such as Business Architecture is seen or managed in isolation of the overarching Enterprise Architecture construct. However the Business Architecture and Enterprise Architecture complement each other well to get the best value from each other. I think that the Business Architecture is one of the key enablers of the Enterprise Architecture and makes it real. While the Enterprise Architecture offers much needed context for the Business Architecture.

It might be useful to briefly review the definitions of both Business Architecture and Enterprise Architecture before understanding issues in their relationship. 

As I have been writing on this blog, Enterprise Architecture should not be limited to the IT or Technology concerns of an organisation. Rather it should be focused on addressing much broader scope covering the business, functional, operational, financial and people aspects of the enterprise. 

There are a number of Enterprise Architecture definitions out there. A couple of my favorite ones are as follows:


Enterprise Architecture provides a strategic planning framework that relates and aligns information technology with the business functions that it supports.


Or


Practice of enterprise architecture involves developing a framework to describe a series of “current”, “intermediate” and “target” reference architectures and applying them to align change within the enterprise. Another set of terms for these are “as-is”, “to-be” and the “migration plan”.



The Business Architecture Special Interest Group of Object Management Group (OMG) defines Business Architecture as follows:

“A Blueprint of the Enterprise That Provides A Common Understanding Of The Organization And Is Used To Align Strategic Objectives And Tactical Demands.”


“Business Architecture describes the product and/or service strategy, and the organizational, functional, process, information, and geographic aspects of the business environment”

I think that though the practice of both Business Architecture and Enterprise Architecture has matured over the past few years, there certainly are some issues when it comes to these two working well together. I have summarised them in four broad arguments;

  1. Business Architecture not done at all. Enterprise Architecture teams only perform Enterprise Technical Architecture only.
  2. Business Architecture done in isolation of Enterprise Technical Architecture and then (if lucky) artificially superimposed
  3. Business Architecture and Business Context Confusion: confusion between why, what and how
  4. Technology focused governance: only conversations about technical standards, business governance disconnected from IT investment and decisions leading to critical gaps
I have tried to capture this pictorially below:

BA & EA in Isolation
This issue is getting wider acknowledgment given its strategic importance. I particularly like Randy Heffner’s work in this space. He states in one of his blogs;

“Simply positioning business architecture as a layer on top of existing EA domains is a mistake. Traditionally many organisations have pursued EA as Enterprise Technical Architecture (ETA). ETA is technology-centred.  Business architecture is business-centred. Simply layering it on top of ETA will result in tech-centred silo implementation.”


As Business Architecture Special Interest Group of Object Management Group(OMG) states, the Business Architecture defines the structure of the enterprise in terms of its governance structure, business processes, and business information. In defining the structure of the enterprise, business architecture considers customers, finances, and the market to align strategic goals and objectives with decisions regarding products and services; partners and suppliers; organization; capabilities; and key initiatives. Business Architecture primarily should focus on the business motivations, business operations and business analysis frameworks and related networks that link these aspects of the enterprise together and it should be seamlessly integrated with Enterprise Architecture efforts within the organisation. 

In my experience to tackle above listed issues, following measures can be taken by the Architecture team;

  1. Business Architecture as part of Enterprise Architecture
  2. Business Architecture drives Enterprise Architecture domains
  3. Business Architecture and Business Context clarified and integrate
  4. Business aligned Technology governance


My pictorial representation from earlier changes as below now:


BA & EA in Collaboration

Modern Enterprise Architecture teams and Enterprise Architects can not longer afford to ignore the implications of Business Architecture. Likewise, modern business architects can no longer afford to work in isolation of organisation’s enterprise architecture. 

In conclusion of this article I would like to summarize my thoughts as follows:

  1. Enterprise Architecture in isolation of Business Architecture is simply Enterprise Technical Architecture
  2. Business Architecture should guide the development of Enterprise Architecture domains
  3. Business Architecture combined with Enterprise Architecture is a powerful tool for business-IT alignment
  4. Strategic Frameworks and Models help in achieving this alignment

And as Chris Potts would argue, the Chief Executive of an Organisation should be ultimately accountable for ensuring the two come together as we would expect him or her to be the Chief Enterprise Architect of the Enterprise!

For related articles:

Agile Business Modeling – The Core Heuristic?

by

How many times have I heard that the real problem with Agile is getting to the start line? There has to be some definition up front, but Agile methods don’t really help. Perhaps it’s a little secret for many organizations that they feel they must do more specification work up front because it makes it easier to control the Sprints. Oh dear!

To get to this starting gate we need to model the agile business in an Agile manner (YES!). Further we do not want to undertake complete or detailed business architecture (NO!!). We don’t have time, and anyway the core of the innovation and architecture should be done in the Agile Delivery project. But before we can fire up Agile projects we need to determine the scope and charter. If we use conventional scoping methods we may well deliver great functionality very quickly, but we probably won’t, unless we are very lucky, have delivered agile business capabilities that map to the business dynamics and can evolve along with the business.

Here’s a technique that may help.

In the first image below I show a functional decomposition for complaints management which I have clustered into “candidate capabilities” labelled 1, 2 and 3, process management, customer relationships and analysis respectively. This usefully shows that capabilities can be varying levels of abstraction; there’s absolutely no necessity to have elegant models!  The table below the decomposition shows various criteria I used to help me decide on the possible clusters. As you will see there’s variation in strategic classification; the partitioning – which may be key for deployment, some could be centralized others local; and the need for implementation independence and so on.

This analysis certainly helps me present some choices. But aside from the independence and scalability criteria and possibly standardization criteria, I feel I have not fully exhausted the analysis of the need for business agility. In the table below I develop this a little further. First I make an assessment of the potential requirement for future change in each function. I call this Agility Potential (AP) on a 1=Low and 5=High scale [1]. Not surprisingly Analysis and Skills are the capabilities that will probably be subject to considerable volatility. Second I look at the dependencies between the functions; note you have to read this as each row dependency upon a column. And low and behold, Skills and Analysis, and Analysis and Follow-up have high dependencies. This causes me to reconsider my initial cut of capability boundaries. I feel that Skills needs to be very close to Analysis as the investigatory function. And Follow-up should be similarly very close to Analysis. And what’s more these three functions score most highly on the AP scale. I feel Follow-up could easily be collapsed into Analysis, and a name change to Investigation would be perfect. I think a little more deeply about Skills. The degree to which the outcomes of Investigation need to be fed into Skills on a dynamic basis will vary depending on the type of business. If this was a safety critical business, I might recommend consolidating Skills and Investigation and renaming it Knowledge Management. But this really would depend on the business sector specific needs. 
To recap, what I have done here is developed a sharper understanding of the capabilities, and I have attributed them with governance criteria (in the first table) – I know what I must have delivered, and I am communicating some really important information to the delivery team, without constraining them at all on the implementation and delivery method. Also I now know the dependencies between the capabilities, and we can very quickly resolve the services that will be required and the inter project dependencies. And it didn’t take me very long at all.

More on Agile Business Modeling 

[1] I first outlined the idea of Agility Potential in the CBDI Journal April, 2010. Let me know if you would like a copy.

EA Myths

by

A recurring theme in enterprise architecture forums and debates is: “How do we demonstrate the value of EA or justify architectural overhead?” Some may view these discussions as academic, which compounds the problem, because it supports the idea that enterprise architects don’t really understand their role, that they don’t have a common definition of enterprise Read more