Enterprise Architecture and Cloud -- It's an "and" world

[#1]

I was talking with a cloud evangelist the other day and he made the statement that "we're using cloud, we don't need an Enterprise Architecture".

After a comment like that I had to re-booted my mind before I could speak.  

Now you need the enterprise architecture more than ever. Just because you've "outsourced" the technical architecture via the cloud of some of the underlying enterprise components, it doesn't mean that this set of services can stand alone. For most organizations it needs to be integrated into the wider enterprise in order to deliver comparable value.

I view that architecture consists of a number of large grained architecture components:

When you move into a cloud approach a few elements of that particular service will be outside your control. For example, if you use a SaaS provider for CRM, the application architecture, the infrastructure architecture, the information architecture and the service management architecture for that particular service will be outside your control, but you still need to understand if it is functioning, and move information in and out of the service, integrating it with the rest of the enterprise. So some of the content will get smaller (in the EA) for that service and service management will get larger. This is one reason Solution Architecture is separate from but complimentary to Enterprise Architecture.

The organizations EA still needs to conform to a process and be a foundation for governance, otherwise you can get yourself into a chaotic situation whose value delivery is unpredictable.

So it is not a choice between cloud and and EA but more of a need to have an EA to ensure the benefits of cloud, s since the EA is focused on aligning the benifits of technology with the business.

[#2]

I forgot to include a Forrester blog that spurred me into writing this post:

http://blogs.forrester.com/randy_heffner/10-06-18-get_strong_focus_your_approach_cloud

[#3]

Amen Charlie!  Glad the reboot worked!

If technology was the problem then time sharing and COBOL would have solved it.  And if those weren't quite the solution, then certainly CASE, or virtualization, or JAVA, or XML, or use cases, or DBMSs, or ____(insert favorite technology here)____ certainly would do it.  So now it's the cloud (or dare we call it "time sharing" all over again?).  But our real problems are not technical, and they are not building and running systems -- IT folks are pretty darned good at all that, often excellent. 

Our real problems are caused by the fact that we think our problems are technical rather than organizational, and that is why we keep questing the ever-elusive alignment instead of achieving and sustaining it.  In other words, our problems are a result of our how we think about IT and the organizations our technologies are a part of.  Fortunately for us Enterprise Architecture (EA) is about thinking differently about organizations and their technologies.  I sometimes think of EA as requirements analysis and design (RA&D) on steroids and megavitamins, or as a colleague once said "EA is how we should have been doing RA&D all along.  And doing EA and RA&D are actually much more difficult than doing technology. 

Now just in case you dismissed that last sentence before you even reached the period, take a moment to recall what Fred Brooks, computer science professor and master software builder while most of us in IT today were still undifferentiated genetic material, said about this -- “The hardest single part of building a software system is deciding precisely what to build.  No other part of the conceptual work is as difficult as establishing the detailed technical requirements….  No other part of the work so cripples the system if done wrong.  No other part is more difficult to rectify later.” -- "No Silver Bullet — Essence and Accidents of Software Engineering,” 1986, in Information Processing 86. H.J. Kugler, ed., Elsevier, 1069-1076. (Invited paper, IFIP Congress '86, Dublin) Reprinted in The Mythical Man-Month, 20th Anniversary Edition, Frederick P. Brooks, Jr., Addison-Wesley, 1995.

And it's that hard for software because the software is part of something even more complicated and difficult to understand -- an organization or a nuclear plant or a navagation system for an aircraft carrier.  Look, EA is no silver bullet either.  But EA does help us better understand what IT is really all about. 

“The act of discovery consists not in finding new lands but in seeing with new eyes.” – Marcel Proust

Leon A. Kappelman, Ph.D.
  Professor of Information Systems
  Director Emeritus, Information Systems Research Center
  Fellow, Texas Center for Digital Knowledge
    College of Business, University of North Texas
    Voice: 940-565-4698   Fax: 940-565-4935  Email: kapp@unt.edu
    Website: http://courses.unt.edu/kappelman/
Founding Chair, SIM Enterprise Architecture Working Group (SIMEAWG) – Website: http://eawg.simnet.org/

[#4]

Enterprise Architects are in the right place at right time. This is because of the industry phenomena emerging that is driving enterprise architecture capabilities out of corporate shared service information technology -- the phenomena we see is called externalized service delivery. Externalization of applications development, infrastructure operations, and back-office processes will gradually erode the “factory” side of the internal IT function. The pace will accelerate as the cloud enables the externalization of up to 80% of application lifetime spends. As this occurs, internal information technology roles will shift from being technology providers to technology brokers and the scope of the internal “Group IT” information technology function will diminish -- its headcount fall by 75% or more.

Strategy, architecture, risk, planning, and governance will (for the most part – depending on organization) be reallocated from information technology into a shared business services level, not within the information technology function.

Our research disagrees with your observation about  “EA is focused on aligning the benifits of technology with the business.”

We have seen recently three domains that are more inclusive (not the typical business, application, information, infrastructure,…)

1. People – how to people connect, what are their roles, who is in what position, etc.
2. Process – how does the business operate, what are the primary drivers, the transition from resources to capabilities, etc.
3. Technology – Rationalizing technology, visualizing future impact, grasping the risk.

Business, information, application, and infrastructure cross all three groupings.  How do we enable collaboration, automate processes, and build a more solid technology base?  How do we utilize knowledge that we collected along the various processes and maintain this information over time?  How do we define our functions and services, expose them either internally or externally, and build a base of execution for them? 

Enterprise Architectes have one way of structural thinking:

1. Contextual (situational)
2. Conceptual (ideas)
3. Logical (connections)
4. Physical (blueprints)

We organize the collections of people, process and technology to enable the connection from strategic thinking to business execution.

We can look at this in an evolutionary path through:

1. The componentized set of changes (roadmap) moving from current state to future state (products, business components, milestones)
2. The transformational set of changes starting with acquiring resources, maturing them into competencies, and combining/transitioning them into capabilities.
3. The staged governance that allows us to manage risk, set checkpoints, and guide.

[#5]

Alan, when you say your research disagrees with the EA being about aligning technology and business, it leaves me with some questions.

Your domain-oriented view describes a different cross-cutting perspective from how TOGAF or HP's own EA process RightStep divides the sub-structures of EA. The domains of people, process and technology are definitely important components of the thought process, but I didn't see how that differs from the benefits alignment statement. Is your issue that the word "align" implies separation? If that's the case, I fully agree since the industry is moving beyond the days of IT being separated from the business.

If you mean something else, I'd like to hear more about the "one way of structured thinking". Are you suggesting the organizational structure or roles should be aligned to this structured way of thinking or is it just the EA whose approach should change? Anyone who has worked on a large EA realizes that it can spin out of control with too much detail quickly. Will this approach minimize the complexity of the modeling... since (by definition) the first two level remain at a higher level?

I'd especially like to understand the as-is to to-be aspects that an EA needs to define to create a relationship between the businesses goals, initiatives, tasks and metrics... to facilitate delivering business value.