Thursday, July 19, 2012

New Enterprise Architecture Blog - www.enterprise-advocate.com

Please note that this Enterprise Architecture Blog has been replaced by www.enterprise-advocate.com

This page will remain online however all new Enterprise Architecture blog posts will be posted on The Enterprise Advocate web site www.enterprise-advocate.com

We're hoping to make www.enterprise-advocate.com amongst the best Enterprise Architecture blogs on the Internet and to continue bringing the freshest EA thinking. We look forward to seeing you there. :-)


| More

Tuesday, February 14, 2012

2 Enterprise Architecture Jokes

1.   How many enterprise architects does it take to define “enterprise architecture”?

Answer: Well, that depends on what you mean by “enterprise architecture”.

(credit: Matthew De George [comic genius] - http://www.managewithoutthem.com/knowthyshelf)

2.






(Ed. - I cannot find the copyright owner of this image. Please get in touch if it is you and I will attribute it.)




| More

Talking to customers of Enterprise Architecture services

Today, the wonderfully clever Kevin Smith of PEAF fame began a discussion in the Australasian Architecture Network LinkedIn Group.

If I understood Kevin correctly, the general ideas of the discussion were that EA practitioners should be looking at "taking the architecture [conversation] up the food chain (out of project land and IT and into management)." I broadly agree with the view that EA should be part of the organisational management conversation but I would say it slightly differently. I would say that we should "push the conversation up to management AS WELL AS into project land and IT" and indeed onto all relevant parts of your business.

Kevin makes an insightful comparison between Deming & TQM, against Zachman and EA. Kevin "advocate[s] that anyone involved in EA should adopt this approach for explaining EA in order to get organisations to adopt it." It is an adept comparison of methodology but I do not agree that it is a good way to explain EA to management.

I simply think that it is an unnecessarily complicated approach to the task. Indeed, this over-complication is something that we EA practitioners can often been guilty of. It is understandable that we tend toward highly evolved language because we need precise semantic meanings to communicate with each other and with technical experts. So we tend to use specific and highbrow language but (and I have no doubt that Kevin would agree with this) we should really be striving to use language that best communicates our meaning to the person we are speaking to. I also believe that EA can be described to most people in very simple terms.

Is it not enough to explain EA to executives by saying, "EA (verb) is a decision support tool. The enterprise architecture (noun) provides an evidence-basis to support decision-making. EA can help executives make decisions about strategy and it can help implementers make decisions about how to implement."?

When EA practitioners say "domain modelling", can we not explain it to most stakeholders as "a way to put things into categories so that we can sort them and identify where there is either too much or too little of each type of thing. This can also help us understand the costs and risks for each category."?

When EA practitioners say "reference architecture", can we not explain it to most stakeholders as "a system for sorting things, like the Dewey Decimal System used in a library to help you sort types of books."?

When EA practitioners say "alignment mapping", can we not explain it to most stakeholders as "a way of showing how things connect, like the parts list and assembly instructions in an IKEA product."?

In these days, where optimizing customer experience is essential for success, EA practitioners really need to think, "how can we optimise the experience of the customers of the EA services that we provide."
Famed architect Vitruvius’ wrote in his book “De Architectura” way back in 15 BC that all architecture must be 3 things: “useful, solid, beautiful.” Simple forms of communication lead to each of these 3 fundamental goals.



| More

Sunday, October 30, 2011

Enterprise Architecture Frameworks for the knowledge economy?


(Warning: This post is basically me thinking out loud, it may not have a conclusion) 

Out there in the blogosphere, the most common argument about EA is between those that think EA is about architecting the whole enterprise and those that prefer a more IT centric view. I've always felt that this rather pointless, navel-gazing argument has distracted our profession from more relevant discussions about how EA can deliver value.

One thing that I have felt for some time, is that EA frameworks are often primarily derived from or based on commercial manufacturing models. Further, they usually have a strong flavor of operating excellence over customer intimacy or product leadership (See "Discipline of the Market Makers" by Michael Treacy and Fred Wiersema).

So I am always on the lookout for frameworks that appreciate other viewpoints that may be useful for delivering value using EA. Examples:



Even though there are examples of frameworks using different viewpoints from the commercial, manufacturing, operating excellence viewpoint; I am yet to really see a framework that is built from the ground up, to focus on a knowledge-business rather than a manufacturing-business. 

Yes, some, if not all, of the frameworks above CAN be used for EA in a knowledge-business. In fact I have personally used each of them in this way; but I have always felt that I needed to adapt these frameworks to suit the context of a knowledge-business. (Note: Yes, I know all frameworks are a starting point and that they always need to be adapted to fit context. That's not the point that I am making here. *grin*)

It is just that I wonder if there is any merit in developing a framework that is built from the viewpoint of managing a knowledge-business. First let's ask why this might be meaningful.

I read a newsletter on the weekend. It was posted on Microsoft UK's web site by Mike Lloyd, an Independent Consultant on the Microsoft Architect Council. Mike was writing about the new Microsoft Business Architecture Framework - "Motion".  (As far as I can tell, MS Motion is in beta at the moment but I would love to hear from anyone with more concrete information as to the status of MS Motion.)

The Microsoft Motion Business Architecture Methodology

Mike wrote

"knowledge-based work is not similar to production activity. Where handoffs in industry produce economic benefits, the handing off of knowledge work creates delays and discontinuity."


Ah ha!! So someone else out there thinks that there is a difference between manufacturing and knowledge-based work.

Mike then gives an example of what he means"

"Ask any customer who has navigated the labyrinth of a conventional banking organisation's customer services trying to find where their application has gone and frequently answering the same questions over and over again as their case is moved from team to team."

Not a great example but it does highlight that in this (example) bank business, the issue lies primarily in processes, knowledge management, organizational design, etc. Things that TOGAF and a raft of the other major EA frameworks don't have a whole lot of useful guidance about. (Oh no, did I just slip back into the architecting the whole enterprise vs EWITA arguament by accident there?)

Anyway, I'll probably post more about this as I haven't really reached any conclusion.

Generally what I am getting at in this post is that I have a general impression that the frameworks, case studies and research material (e.g. Gartner & Forrester) don't tend to have a sharp focus on knowledge based businesses as much as they do on manufacturing based business; and so I am wondering if there is any merit in having one. (or should I just keep using the current frameworks with their 80% fit?)

Anyway, I'll just be over here putting on my flame retardant suit in case I have offended anyone! *smile*









| More

Wednesday, April 6, 2011

Enterprise Architecture as Business Capabilities Architecture

"Why do enterprise systems like SAP fail in some companies yet succeed in others? Clearly, the interrelationship between technology and process, skills and culture was not taken into account." Dana Bredmeyer in Enterprise Architecture as Business Capabilities Architecture http://www.bredemeyer.com/pdf_files/Presentations/EnterpriseArchitectureAsCapabilitiesArchSlides.PDF

I've posted this quotation because I think it was the first time anyone really started to focus on the people and culture as essential to successful EA and on enterprises as 'socio-technical' systems.

The article itself is a classic and a must read for any EA. It shows the extension for IT architecture with an enterprise wide scope into EA as architecture of the whole enterprise. It was written in the first half of the last decade and only in the last couple of years have the likes of Forrester really turned thier attention to capability maps, etc.


| More

Wednesday, February 23, 2011

Enterprise Architecture's Obsession with Efficiency

Jeff Scott recently wrote a great blog "Is the current EA paradigm right for business architecture?"

http://blogs.forrester.com/jeff_scott/11-01-25-is_the_current_ea_paradigm_right_for_business_architecture

The comments section was full of erudite responses from several of the leading thinkers in EA. I'd like to pick up on two of the comments:

Tom Graves

"Most people seem to be obsessed by efficiency, but what we're really after is effectiveness"
As always Tom has been insightful and this is something that I have been reflecting on. I've noticed that nearly all of the EA literature and frameworks come from or refer to manufacturing businesses. Case studies and examples are always about manufacturing and rarely about service providers or knowledge-centric businesses. They are nearly always about commerce and much less often about government or non-profit where motibvation and accountability create very different cultures. This is a failing of us as the EA comunity and a reflection of the maturity of this discupline.

Kris M

"Unfortunately the failure of enterprise architecture is also that of a wider failure ... a society that obsessed with efficiently operating but narrowly interested in reflecting whether strategy and structure ...[is] effective and sustainable."

Another enlightening comment from Kris that observes that, through human history, there has been a percieved need to grow, espeically in capitalist economies. As we are currently facing the first real global threat to human existence. There is an slow realisation occuring that we have grown enough and that balance in the system will need to become our primary driver . This is both in a planetary sense and also an industrial sense. We are getting to the point where people in the west are looking for work life balance. It is starting to become realistic for some people, rather than asking for more salary, they are asking for the same salary with less work (e.g. 9 day fortnight). Balance.

All of the above reflects on the weakness of curent EA paradigms being generally an extension of industrial engineering where, as Nigel Green puts it in his book Lost in Translation (great book btw) "users want a system that works the way they do, which is often amenable to change and supports learning. The IT specialist, on the other hand, seeks a high degree of certainty and actionable rules that can be configured or encoded." Efficient but not necessariy efective.
 
| More

Thursday, February 10, 2011

Sample Set: Enterprise Architect Interview Questions

I'm interviewing an enterprise architecture candidate today. His CV suggests that he is an enterprise IT solution architect so I am going to probe a bit and see if he understands architecture of the enterprise. Here's some questions I have jotted down as a framework for my own thinking. I'm sharing it in case it is useful to anyone else out the in the #entarch community.

What does "enterprise architecture" mean to you?


What are the benefits of EA?

Why would businesses come to SMS for EA services? What business problems can be addressed through EA techniques?

What business outcomes have you influenced using EA in the past? What metrics did the business use to measure these outcomes? Give 2 examples.

What are the contributing characteristics and attributes that make for a good EA?'

Where should the EA function sit in an organization?

What is the best EA artifact that you have seen and why?

What is the worst EA artifact that you have seen and why?

What is the best EA artifact that you have produced and why?

What is the worst EA artifact that you have produced and why?

What is the relationship between EA and portfolio management?

What is the relationship between EA and risk?

How could EA be use to support operational management activities?

What are the key determinants of success for an EA program? (Gartner says statistically, stakeholder involvement and support is #1. I would be concerned if I didn’t hear the words “deliver business value” in the response too.)

Describe an example of business architecture that you have been involved in. What was the outcome of that activity?

Describe an example of information architecture that you have been involved in. What was the outcome of that activity?

Describe an example of technology architecture that you have been involved in. What was the outcome of that activity?

Can you describe two EA frameworks and how you have applied them?

Can you explain the role of communication planning in EA and what type of stakeholders have been key in your EA experiences?

What is a business capability and how is it relevant to EA?

Describe an EA governance structure that you have experienced in your career. What were the pros and cons of the structure?

What is the difference between EA and enterprise IT architecture?

What dimensions would you measure if you were asked to conduct an EA maturity assessment in a client site? (I’d be looking for EA scope & authority, stakeholder involvement & support, achitecture definition process, linkage to business strategy, measured business value, coverage of the Eas content, future-state definition, EA team resources, EA impact & measures.)
 
| More

Thursday, November 25, 2010

Reasons that business may come asking for “Enterprise Architecture”

This article could also be entitled "Reasons business may come asking for help, where enterprise architecture thinking and techniques can be applied (without mentioning EA)"

At the start of 2010 I was working on developing the "Enterprise Architecture" service offering for a consulting firm in Australia. As I thought through the development of this capability I started by considering the demand and who the demand would come from.

The consulting firm revenue model is based on providing professional services and frankly virtually no one in Australian business has the first clue what EA is and nor should they. So selling enterprise architecture in my view would be poor strategy (unless a client asks for it directly) If I'm out there trying to sell "EA" to executives I have almost certainly failed on a number of levels.

Defining enterprise architecture, understanding enterprise architecture frameworks and other forms of trivia are useful for practitioners leaning what EA is and how to do it. This is in the same way as knowing what a car is and how the accelerator works is useful for learner drivers.

Enterprise architecture is not the driving but the destination and the journey, including the human meaning (emotion) of the experience and the people that help or hinder you in arriving at the end point of each trip or at each way point in your ongoing travels. EA is also much like all of the things that go into designing a formula one car and winning a formula one race with all of its pitfalls and hard learned lessons. If you can only afford one EA, hire one that can tell the tales of their battle scars; those guys are far more likely to understand the human dimension for enterprise architecture that is missing from just about all of the literature on EA.

So selling enterprise architecture is like offering driving lessons to someone that just want's to go on holidays to a wonderful (valuable) place. In order to get an idea of what service offerings we should develop, I thought through the types of business problems that the staff in the consulting firm might be hearing from business people in their dealings.

Some examples of problems that I have heard from business people (clients) this year include:

  • (CEO) "My project portfolio has too many failures"
  • (CEO) "Magazine subscriptions are in decline I need to find a new revenue model"
  • (Chief Strategy Officer) "We don't have a good handle on our information, we can provide better service if only we could combine our data more easily"
  • (Chief Marketing Officer) "How can I get more revenue out of my existing customers and reduce churn?" & "I want a 360 degree view of my customers."
  • (Government CEO) "A new regulation has been passed how can I understand the impact?"
  • (Banking Executive) "How can we differentiate from our competitors"

Below is a list of a few areas where I have applied enterprise architecture to respond to business concerns. I have listed a few areas that I can think of where EA can be applied to address business concerns. From this it would be easy to identify some 'services' that EAs can provide and some of these can be readily packaged as solutions for consultancy firms to take to market.

Strategic Planning

  • Business strategic planning (Define the corporate Vision, Goals, Strategy & Objectives)
  • Define the business technology (the artist formerly known as “IT”) component of corporate strategic planning
  • Demonstrate alignment (or otherwise) between any two or all of the following:
    •   business strategy
    •   business capabilities
    •   business process
    •   information assets   
    •   application assets
    •   technology assets
    •   any other useful viewpoint
  • Facilitate Innovation Strategy
  • Provide technology trend & hype curve analysis
  • Provide an evidence basis for asset portfolio management (lumps & gaps analysis + asset valuation)
  • Provide an evidence basis asset life cycle forecasting & management
  • Provide an evidence basis & structured approach to guide initiative (i.e. projects & programs) 
  • portfolio management

Governance: Provide an evidence basis & structured approach for

  • Investment Governance (Decision frameworks)
  • Business Case development
  • Business case options development & review
  • Architectural Governance
  • Performance measurement
  • Integrated risk assessment & management

Strategy Execution

  • Connecting strategy, to execution (initiatives) and assurance (outcome measurement)
  • Program & Initiative management \ assurance \ recovery
  • Policy implementation planning \ impact assessment
  • Business process enhancement & automation
  • Information management maturity
  • Compliance & reporting

Managing complexity (businesses that have so many or such complex problems they don’t know where to start)

  • Major Initiatives
  • Provide a method for roadmap development
  • Facilitate change management:
  • Use EA to articulate the changes that need to be made to achieve planned outcomes so that all participants have a common understanding of the change and the outcome
  • Use EA to help understand the human aspects of change (ADKAR)
  • Major system design &  implementation (e.g. ERP/CRM)
  • Legacy systems upgrade. (How do I make a change to a complex system)
  • Capacity forecasting and management (The capacity of people & of things)
  • Solution architecture & design services (Some people still think this is EA. They’re right and wrong. If you can’t handle right & wrong coexisting you’re probably not going to be a good EA)
  • M & A or divestment planning & execution

Outright architecture definition

  • Define the Business architecture
  • Define the Information architecture
  • Define the Application architecture
  • Define the Technology architecture
  • SOA implementation
  • Define the Security architecture

Raw EA Capability Development

  • EA maturity assessment
  • EA skills profiling
  • EA coaching and mentoring
  • EA skills training
  • EA recruitment & selection

PS - This post was prompted by reading the ever-insightful @nickmalik 's blog post "How many business architects do you need?"  http://j.mp/aIvPa7 and I wondered if he had also developed a list of #entarch / #bizarch services.

.


| More

Wednesday, October 20, 2010

Summary of the Business Architecture Working Group's (BAWG) Nobel Prize Case Study

The Nobel Prize Case study workshop was conducted & presented at the Open Group Conference in Amsterdam (2010)
It was an investigation into whether business architecture can be described using natural language rather than any form of modelling language that requires learned semantics (meaning).
This post is my extract of the proceedings as they relate to business architecture. There were other dimensions to the presentation including details of why the Nobel prize was selected for the case study etc and full details can be found here.
“Business architects understand that a controlled way is required to convey properties to enhance the design, development and maintenance phase.”

Why is this so difficult?

The business intent travels along many disciplines and several management levels.
Selective perception is a problem
Each group has its own selective perception filters on.
Each individual of each group has its own experience.
Each individual has had its own background and training.
This generates different interpretations of what is observed.
It also causes different preferences in representation of the observed item.
The background of stakeholders is always different and this causes a problem.
Communication between disciplines is the problem
The BAWG conducted a case study using members from different disciplinary backgrounds in order to test whether natural, non-technical language could convey the essential elements of business architecture.
After several sessions the BAWG agreed on a list of concepts that serves the purpose when representing the properties of a business.
The list includes
-         vision about the context of the organization;
-         mission; strategic direction
-         the ecosystem of outside participants and influences,
-         organizational structure within the capabilities and processes of the organization,
-         business rules and policies that guide its behaviour
-         the stakeholders of the organization, both inside like employees and outside like customers and suppliers
-         the relationship of capital with its stakeholders,
-         the relationship with society
-         the products, services and offerings,
-         resources used to create them
-         the metrics that provide a way to assess progress towards goals and to track performance
-         the value, both financial and intangible, that is produced, exchanged and transformed by the organization

Conclusion

In natural language we could explain properties of a business. No difficult conventions. These concepts can easily be understood by different disciplines.
The experiment has demonstrated that it is possible to convey the properties of business architecture in a natural and “controlled” language.”


| More

Tuesday, October 19, 2010

Adrian Grigoriu

Adrian Grigoriu's Enterprise architecture framework definition. This is a extract of Adrian's www.ebizq.net blog post "An Enterprise Architecture framework definition". It is a very enlightening post by Adrian at a time when it is (rightly or wrongly) quite fashionable to bemoan the use of frameworks. 

1. EA Process: the EA development process and Best Practices for:
  • EA team organization 
  • EA governance, team and program organization
  • Tools to measure maturity, value created and assess EA business case
2. EA Framework, the meta EA consisting of the specification of
  • Key EA framework elements/patterns
  • Metamodel showing the EA entities and relationships
  • Key Views like Location, Information, Security, Financial, Performance etc
3. EA (Reference) Models
  • Generic Business Architecture, reference functions/capabilities map
  • Typical IT Applications Map
  • Generic Infrastructure architecture
  • Typical organization design charts
4. EA Design method consisting of the key EA artifacts and design sequence using metamodel & framework elements



| More

Saturday, October 16, 2010

The A-Z Guide to Being an Architect





"An A-Z Guide to Being an Architect" by Mark Bloodworth and Marc Holmes is a lighthearted article outlining a number of key attributes of architects. An extract is below. Is there any important attributes missing?

A is for Advocate

“I think you’ll find that you really don’t want to do it like that.”

See also: Abstraction, Agile, Acrobat, Availability, Analysis, Applications

B is for Balance

“A little more to the left. Keep going. A bit more. Not that far. Sorry.”

See also: Best Practice, Benchmarks, Building Blocks

C is for Coach

“Work through the pain!”

See also: Communication, Champion, Context, Collaboration, C#

D is for Dependencies

“What happens if I unplug this? Oh!”

See also: Design, Development, Delivery, Domain, Documentation

E is for Evangelist

“Let me show you something really cool.”

See also: Enterprise, Engineer, Enthusiast

F is for Frameworks

“How do I get there?”

See also: Facts, Functionality, F#, Firewall

G is for Governance

“It is the opinion of the subcommittee...”

See also: Generative Programming, Generalist

H is for Human Dynamics

“The system would have been a success if it hadn’t been for those pesky users!”

See also: Heterogeneous Environments, Heated Debates, High Performance Computing

I is for Innovation

“The lifeblood of any organization”

See also: Integrity, Inspiration, Infrastructure

J is for Judgment

“With great power comes great responsibility.”

See also: Java, Just In Time

K is for Knowledge

“If only I knew then what I know now.”

See also: Kernel, Keyboard

L is for Leadership

“I’m behind you all the way.”

See also: Lean, Linux, Latency, Load Balancing

M is for Modeling

“So, to help us visualize how this might work, I made his model using nothing but twigs and guitar strings.”

See also: Management, Maintainability, Messaging

N is for ‘N-tier’

“A house of cards”

See also: Needs, Networks, Nonfunctional Requirements, .NET

O is for Object Orientation

“Encapsulate this!”

See also: Operations, Object-Relational Mapping, Operating System, OLAP

P is for Patterns

“I think I see something emerging from the chaos. Is it a zebra?”

See also: Principles, Platforms, Politics, Performance, Process

Q is for Quality

“Good enough isn’t good enough.”

See also: Qualifications, Queries, Quantification, Quantum Computing

R is for Roadmaps

“You take the high road, and I’ll take the low road.”

See also: Requirements, Realization

S is for Strategy

“What are we trying to achieve?”

See also: Services, Software, Standards, Security, Scalability

T is for Thinking

“I think, therefore I clearly have too much time on my hands.”

See also: Technology, Transparency

U is for Understanding

“I do believe you’ve got it.”

See also: UML, Unix

V is for Values

“Explain to me again why we’re doing this...”

See also: Virtualization, Visualization, Views

W is for Whiteboard

“It’s probably easier if I just draw a picture.”

See also: Workflow, Wikis, Windows, Web

X is for XML

See also: XSD, XPath, XQuery, XAML, XOML

Y is for YAGNI [You Ain’t Gonna Need It.]

“Stay on target! Stay on target!”

See also: YAML, Yottabyte

Z is for Zeitgeist

“All the cool people are doing it.”

See also: Zeal, Zettabyte, Zero Day Exploit


| More