#eavoices

Launching an Enterprise Architecture Program within State, Local, Municipal Organizations

by

By Gloria Chou

When launching a formal EA program, Government organizations often begin by socializing the overall benefits of EA and developing an EA Charter and Plan.  However, while both of these are valuable, they are more useful as part of after-the-fact documentation and communication plans.  Having worked with a broad spectrum of government organizations across the US and Canada, our team, Oracle’s Public Sector Enterprise Strategy Team (EST), has found that the first and primary focus in launching an EA program should be on how to meaningfully engage top business leaders and other stakeholders to discover their needs, identify what would bring the most value to the organization, and obtain their buy-in and support for EA as a key enabler in helping the organization achieve its mission objectives. 

Why is launching (or re-launching) and EA Program relevant in the government space today?  Although state and local agencies may have had an EA team for years, many are just getting started on formalizing their practice and creating awareness of the team’s capabilities and purpose within the organization as a whole – though some are in fact successfully delivering Agency-wide Enterprise Architecture value.  Additionally, while a majority of Federal agencies have necessarily had established EA programs for over a decade in response to Clinger Cohen mandates, some are beginning to reshape their programs as they perceive the need to go beyond checkmark/compliance-based EA and demonstrate additional value to their respective organizations.  Governmental budget pressures are increasing the scrutiny on all resource allocation and deployment such that EA programs must stay relevant and drive acknowledged and desired benefits or else risk being cut.

I believe discovery and dialogue with executive leadership about their goals, objectives, strategies, and current planning processes has to come first as, only after this is known, can the team understand what is particularly valuable to the specific organization.  Too many Government EA programs seek to provide generic value and benefits, such as standardization and integration, that, while good aims in and of themselves, are not necessarily prioritized by the organization nor sometimes even compatible with their operating model and culture.  As a case in point, when working with a very large municipality in the West, the EST began discussing EA with a new, forward-thinking CIO who had been three months into establishing an EA program to change the way IT was viewed across the organization.  We had an initial meeting with the lead EA and found that the new EA team had been doing the expected: technology architecture current state analysis and building IT standards documents.  After three months, the team was well on their way to spending another year or more on documentation!  The question we posed was, how does this change the way IT is viewed across the organization? The answer was clear, it didn’t.  Understanding specific needs, gaps, and opportunities that the executives care about is essential to ensure EA is relevant and focuses on what the business needs to successfully execute on its strategies.   

Based on this understanding of the organization’s priorities and what would bring the most value, the EA team should analyze what needs to be done and propose how they can be a part of the solution.  In the example of the large municipality mentioned above, the EST helped the organization’s EA team identify areas of opportunity to engage with business leaders across the organization and facilitate meetings to better understand strategies, goals, capabilities and high-level value streams.  By starting here, we were able to get the EA team on a path to make better decisions on where they would invest their time to provide the most value to the enterprise.  As a part of this, the team needs to assess their own capabilities and competencies as well as that of other teams within the organization against what is needed and propose options as to how they might best help the organization and what other changes might be needed to achieve the organization’s goals.  In actuality, an EA approach would help facilitate this analysis and assessment of how EA itself could benefit the organization.  The team should consider developing the vision for change as well as current state and future state views of operations, analyzing the gaps, and developing recommendations and a roadmap for the successful introduction of EA into the organization.

Only after the recommendations have been presented, vetted, and selected by leadership should the team document the EA purpose, application, and approach.  While this information can be captured in the EA Charter and Plan, it only represents a part of the needed content.  The rest, especially the plan, can only be developed after seeking input from other stakeholders in the organization.  Even though the executives have weighed in with their input, direction, and approval, it is still often difficult to get an EA initiative started because so many other stakeholders also need to be convinced of the value.  For example, LOB leaders, business managers, and functional SMEs all have to be convinced of the value of EA or else they will not allocate the time and resource required to participate in facilitated sessions and verify/validate the architecture.  Executives and LOB leaders are critical in setting the vision for the future and describing the general goals for operations as well as communicating their overall investment and technology strategies.  However, even if the executives and leaders buy-in, the lower levels also have to perceive value/benefit or else they will put in minimum effort when you really need them to be fully engaged to provide detail as to the reality of operations, challenge the status quo of how things are done today, and ultimately take ownership of the architecture and support the transition to the future state.  Without the business fully on board, the EA recommendations and transition look good on paper but will never be executed. 

Similarly, other stakeholders including Corporate Strategy, Portfolio Management, Project Management, Lean/Six Sigma, and IT also need to fully support EA as they are also critical in the development, execution, and enforcement of EA.  The stakeholders in these other disciplines sometimes feel that EA encroaches on what they do and do not understand why it is necessary.  For example, Lean/Six Sigma practitioners and some business analysts already have great relationships with the business and have already documented and analyzed processes such that they believe they have already “modeled the business” such that EA business architecture development and analysis is extraneous.  IT organizations often point to their UML diagrams, systems engineering drawings, and infrastructure server drawings and say that they are already doing EA.  In seeking buy-in from these other groups, it is very important to first seek to understand and acknowledge the current state of operations – existing skills, processes, and assets – before proposing a future state of how EA enhances/complements.  Formal stakeholder analysis and RASCIs can be helpful, but I believe an attitude of respect for what others do and a collaborative approach is also critical as there are many organizational change issues and related sensitivities associated with introducing EA as a discipline as with any other transformation.  Once general buy-in and support for EA is established, the disciplines need to work out details around overall processes, governance, timing, inputs and outputs to understand synergies, cooperation, etc.  Again, this is something that can be documented via EA, further decomposing views that were used in the overall analysis for the introduction of EA.

Conference presentations and workshops

by

 

I have a few new conference dates coming up. I will be presenting on Visual Stories at the Gartner EA Summit in London on May 14/15, and hosting a roundtable after the presentation.

Find out more and book your space at the conference website.

http://agendabuilder.gartner.com/EPAEU13/webpages/SessionDetail.aspx?EventSessionId=824

I will also be delivering a one day workshop on the use of CAST and visual storytelling at a workshop that preceeds the Enterprise Architect Europe conference and the Business Process Management conference in London on June 11th 2013.

Sign up on the conference website.

http://www.irmuk.co.uk/eac2013/workshops.cfm#w2

Very Qool

by

If you’ve got Windows 8 then there’s now a free app you can download to help create the Visual Story Map, which is the core model in the visual storytelling approach from my book Stories That Move Mountains. Qool (http://qool.598studiosinc.com/) allows…

Bad Habits Cause IT Talent Shortage

by

This morning I read a blog post by Nick Corcodilos “Ask The Headhunter: The Talent Shortage Myth and Why HR Should Get Out of the Hiring Business” and it seems Nick and I have come to a similar conclusion – the talent shortage is self-imposed. My Field Research Summary “The Changing IT Career” is about […]

The post Bad Habits Cause IT Talent Shortage appeared first on Mike Rollings.

Unfounded Reasons People Tell Me Why They Can’t Do Enterprise Architecture

by

I have been working in the area of Enterprise Architecture for 40 years and people have been telling me (and are still telling me) the reasons why they think it is impossible to do Enterprise Architecture.  I think I have distilled these reasons down to five basic objections.  Let me enumerate their objections before I explain why these objections exist and why they are completely unfounded.

First of all, by its very name, Enterprise Architecture implies ENTERPRISE-WIDE descriptive representations, models, architectural depictions and:

a.  “It would take too long and cost too much … ”  

b.  “Enterprise-wide models would be so big and so complex, who could understand them or do something with them even if we could build them? … “

c.  “You don’t need Enterprise-wide models to get some one system built, deliver Enterprise benefit (immediate gratification) and actually, the SMALLER you make the systems the faster you can deliver them and derive benefits … “

d.  “To simply build Enterprise-wide models that could be understood and have any communication value, they would have to be so abstract they would have little implementation value.  They could not be correlated with the reality of instantiations … “

e.  “Enterprise-wide models, however robust, are only a picture, a snapshot, a point-in-time representation.  They would likely go on a shelf and never be referred to again … “

In fact, a very well-known CIO recently stated at a major IT conference that he had terminated a number of Enterprise Architecture projects that just produced pictures and went on shelves never to be used and he saved the Federal Government billions of dollars.

The problem with all of these objections is, the folks who are voicing them are NOT TALKING ABOUT ENTERPRISE ARCHITECTURE!!!

The REAL problem with all of these observations (objections) is, the underlying assumption is COMPOSITE, multi-variable, implementation models, typical models we employ in IT, the MANUFACTURING paradigm … the paradigm that has prevailed in the DP/IT community for 75 years since the inception of computer technologies.

Basically, the end object for 75 years or so has been (and is) to replace people with machines because machines are better, faster and cheaper than people.  Machines are better than people because they do things the same way every time (and people make mistakes), machines are faster than people because machines run at electrical cycle speeds (and people run at people cycle speeds) and machines are cheaper than people (in most cases).  Better. Faster. Cheaper.  The value proposition for system implementations is “cost-justification” (how many Full Time Equivalents will the new system replace? … or, how much value is delivered in terms of the development and implementation costs?), expense-based value propositions.  There is great incentive to get the systems implemented as quickly as possible because every moment the system is NOT implemented, it is costing the Enterprise quality (or capability), time and money (better, faster and cheaper)!

The problems (objections to) Enterprise Architecture is NOT Enterprise Architecture … the problem is what people typically PERCEIVE to be Enterprise Architecture which is derived from the expense-based, implementation value proposition which is NOT Enterprise Architecture, because…

Implementation is NOT architecture

Multi-variable models are NOT single-variable models

Composite models are NOT PRIMITIVE models

Manufacturing is NOT Engineering

Building and running systems is NOT engineering Enterprises

Expense-based valuation is NOT Asset-based valuation

AND

Enterprise-wide COMPOSITE models are NOT ENTERPRISE ARCHITECTURE

All the above reasons why you can’t do Enterprise Architecture are perceived from the perspective of building and running systems, which has been the DP/IT paradigm for 75 years.  Enterprise Architecture has nothing to do with building and running systems.  Oh yes, you could use stored programming devices and electronic media for realizing your Enterprise formalisms, but you also could use pencils, paper and file cabinets … and people.  And … if you had ENTERPRISE ARCHITECTURE, Single-Variable, PRIMITIVE models, they could be used (re-used) for formalizing systems, automated AND manual systems, for that matter.

I would suggest that the Information Age paradigm is not about Building and Running Systems (an expense-based concept) BUT about Engineering and manufacturing ENTERPRISES (as asset-based concept), that is, ENTERPRISE ARCHITECTURE, a different paradigm, a NEW paradigm, which has to do with engineering ENTERPRISES to be “lean and mean”, integrated, flexible, interoperable, aligned, dynamically reconfigured, “mass-customized”, etc. These are engineering-derived characteristics … NOT implementation-derived characteristics.  Building and running systems does not produce these characteristics for the Enterprise as evidenced by the preponderance of legacies that exist in Enterprises today.

The legacies were (are) GOOD … they served well for the Industrial Age.  Automated (and manual) systems are not going to go away.  However, the future, the Information Age, requires ENTERPRISES to be integrated, dynamic, “lean and mean” and so on.  ENTERPRISE ARCHITECTURE.  That is a DIFFERENT paradigm.  Yes, we must produce short term results.  No, short term demand is not going away.  Yes, some of those results may consist of replacing people with machines.  Yes, you must employ methodologies that create Enterprise-wide Architecture iteratively and incrementally but these methodologies require ENGINEERING Models, single-variable models, “PRIMITIVE” Models, different models from those multi-variable, composite models we have traditionally used for implementations, for building and running systems.

It is the composite model, implementation paradigm, building and running systems mentality that causes us to misperceive Enterprise Architecture as being unnecessary, impractical and impossible. In contrast, I just watched my friend Sunil Dutt Jha of iCMG, in the Zachman Certified Modeling Workshop, conclusively demonstrate use of and reuse of “primitive”, single variable Enterprise Architecture asset components to dynamically diagnose, address, simulate urgent CXO strategies while building Enterprise Architecture iteratively and incrementally. He proved it is cheaper and faster, a LOT cheaper and faster than the traditional building and running systems approach. It is not mysterious … it is simply changing the IT manufacturing strategy from producing finished goods (composites), implementations, to an IT engineering strategy, producing re-usables, assets, (primitives), for mass-customization of the Enterprise while solving immediate C-level executive problems.

I wrote an article in 1999, “Enterprise Architecture: The Issue of the Century” in which I argued that those Enterprises that can accommodate the concepts of Enterprise Architecture will have the opportunity to stay in the game … and, those Enterprises that cannot accommodate the concepts of Enterprise Architecture are not going to be in the game.  In fact, I actually believe that.  In fact, you can see a lot of Enterprises falling out of the game these days … big … and small … private … and public.  (Refer to the newspapers.)

Author

John A. Zachman

EA Voices: The Book

by

Dear EA bloggers, Thanks to you, EA Voices is a great source of enterprise architecture wisdom. Now aggregating blogs and writings by over 100 bloggers, the database is rounding 2 million words, and grows with around 100 posts monthly. I think all this wisdom deserves even more attention than the website and apps can offer, and …

Read more

From Enabling Prejudices to Sedimented Principles

by

In my post From Sedimented Principles to Enabling Prejudices(March 2013)  I distinguished the category of design heuristics from other kinds of principle. Following Peter Rowe, I call these Enabling Prejudices.

Rowe also uses the concept of Sedimented Principles, which he attributes to the French philosopher Maurice Merleau-Ponty, one of the key figures of phenomenology. As far as I can make out, Merleau-Ponty never used the exact term “sedimented principles”, but he does talk a great deal about “sedimentation”.

In phenomenology, the word “sedimentation” generally refers to cultural habitations that settle out of awareness into prereflective practices. Something like the “unconscious”. (Professor James Morley, personal communication)

“On the basis of past experience, I have learned that doorknobs are to be turned. This ‘knowledge’ has sedimentated into my habitual body. While learning to play the piano, or to dance, I am intensely focused on what I am doing, and subsequently, this ability to play or to dance sedimentates into an habitual disposition.” (Stanford Encyclopedia of Philosophy: Merleau-Ponty)

This relates to some notions of tacit knowledge, which is attributed to Michael Polyani. There are two models that are used in the knowledge management world that talk about tacit/explicit knowledge, and present two slightly different notions of internalization. 

Some critics (notably Wilson) regard the SECI model as flawed, because Nonaka has confused Polyani’s notion of tacit knowledge with the much weaker concept of implicit knowledge. There are some deep notions of “unconscious” here, which may produce conceptual traps for the unwary.

Conceptual quibbles aside, there are several important points here. Firstly, enabling prejudices may start as consciously learned patterns, but can gradually become internalized, and perhaps not just implicit and habitual but tacit and unconscious. (The key difference here is how easily the practitioner can explain and articulate the reasoning behind some design decision.)

Secondly, to extent that these learned patterns are regarded as “best practices”, it may be necessary to bring them back into full consciousness (whatever that means) so they can be replaced by “next practices”. 

Bryan Lawson, How Designers Think (1980, 4th edition 2005)

Peter Rowe, Design Thinking (MIT Press 1987)

Wilson, T.D. (2002) “The nonsense of ‘knowledge management‘” Information Research, 8(1), paper no. 144

 Thanks to my friend Professor James Morley for help with Merleau-Ponty and sedimentation.

Why projects fail? Hint – It’s not technical skills.

by

A large area of concern for many Gartner clients is “How do I get a large organization to do new things, to collaborate effectively, and to improve overall delivery effectiveness?” This area is a huge focus for our Professional Effectiveness research – it not only applies to architects, but also to our entire constituency of […]

The post Why projects fail? Hint – It’s not technical skills. appeared first on Mike Rollings.

TOGAF Good or Bad? – Definitely Ugly!

by

I’m struggling with the value of TOGAF on my current assignment.

Background:


·        We have a need to develop architectural thinking up the ‘food-chain’ to the C-level to help inform business strategy.

·        The IT Leadership want to focus on: agility & resilience (fast response and ability to thrive under constant change), security, value-for-money and continuously improving User Experience

.

·        Unusually for a private company, we are not currently focused on competition (we are a monopoly) nor inefficiency (labour cost – we rarely ‘let people go’).


·        We have established business-engaged governance mechanisms around Cyber Threat, however, there’s cultural resistance to Western-style Governance practices and methods in other areas.


·        The IT department is mostly seen as a Cost Centre, although we are making some progress here.


·        English is the second language for the vast majority of our employees.


·        Experienced Enterprise Architects are rarer than hen’s teeth in Hong Kong.


·        A few on my team have been trained and ‘Certified’ in TOGAF (mostly before I joined) but they have not actually practiced EA (for a wide variety of reasons) since attending the course.

Observations:


·        TOGAF is hard to comprehend for those whose 1st language is English, so it’s an even greater challenge for my team.

·        TOGAF just tries too hard and ends up failing on a few counts; it’s too comprehensive to be a usable framework and not specific enough to be a methodology. It’s almost a philosophy, but a very incomplete and, at times, dangerously misleading one. This is very hard for my team to make sense of and I find myself having very long conversations with them where we end up agreeing that we reduce or focus on one or two of the TOGAF concepts (usually around a deliverable).

·        TOGAF doesn’t seem to help very much when it comes to the challenges we face around Consumer-led IT.

·        TOGAF does encourage SOA, that would help our agility & resilience goal eventually, but we’re quite a way from developing a genuine component-based, shared-services architecture due to the business organisation, culture and funding mechanisms. And we can’t wait for those to change to be able meet our agility & resilience needs.

·        It’s fair to say,TOGAF training does help introduce newbies to some important EA perspectives and does help with common terms and concepts, but it requires a lot of additional buddy-work with an experienced architect to become useful and, what’s worse, it conveys the wrong message; ‘Enterprise Architecture is complicated and requires a high intellectual capacity to understand’. The latter being the absolute opposite of what I need to convey across IT and the business; ‘Enterprise Architecture is about joining-the-dots and making things simpler to understand’.

I do continue to put my team through TOGAF Certification. Why? It’s the only credible option here getting newbies up-to-speed on the basics of EA/SA and it helps my staff build their CVs (which is important). I just wish there was a better option that was both less and more:



and


  • more – on the basic mentality required of of an EA (e.g ability to abstract) and why all organizations take a different approach to architecture based on culture, maturity and business priorities.

I sometimes wonder if the authors of TOGAF are motivated to make it more understandable, or, as seems to be the case, keep it obscure and arcane. It certainly felt that way when I was exposed to IAF (Capgemini’s Framework) and its zealots for the first time.

An aside here: in a recent chat with the Chief Architect in a well-known travel company, I said I needed the 80 page version of TOGAF – he laughed and responded that he’d implemented an 8 page version! BTW: all his architects are native-English speakers hired in from abroad.

TOGAF Good or Bad? – Definitely Ugly!

by

I’m struggling with the value of TOGAF on my current assignment.

Background:


·        We have a need to develop architectural thinking up the ‘food-chain’ to the C-level to help inform business strategy.

·        The IT Leadership want to focus on: agility & resilience (fast response and ability to thrive under constant change), security, value-for-money and continuously improving User Experience

.

·        Unusually for a private company, we are not currently focused on competition (we are a monopoly) nor inefficiency (labour cost – we rarely ‘let people go’).


·        We have established business-engaged governance mechanisms around Cyber Threat, however, there’s cultural resistance to Western-style Governance practices and methods in other areas.


·        The IT department is mostly seen as a Cost Centre, although we are making some progress here.


·        English is the second language for the vast majority of our employees.


·        Experienced Enterprise Architects are rarer than hen’s teeth in Hong Kong.


·        A few on my team have been trained and ‘Certified’ in TOGAF (mostly before I joined) but they have not actually practiced EA (for a wide variety of reasons) since attending the course.

Observations:


·        TOGAF is hard to comprehend for those whose 1st language is English, so it’s an even greater challenge for my team.

·        TOGAF just tries too hard and ends up failing on a few counts; it’s too comprehensive to be a usable framework and not specific enough to be a methodology. It’s almost a philosophy, but a very incomplete and, at times, dangerously misleading one. This is very hard for my team to make sense of and I find myself having very long conversations with them where we end up agreeing that we reduce or focus on one or two of the TOGAF concepts (usually around a deliverable).

·        TOGAF doesn’t seem to help very much when it comes to the challenges we face around Consumer-led IT.

·        TOGAF does encourage SOA, that would help our agility & resilience goal eventually, but we’re quite a way from developing a genuine component-based, shared-services architecture due to the business organisation, culture and funding mechanisms. And we can’t wait for those to change to be able meet our agility & resilience needs.

·        It’s fair to say,TOGAF training does help introduce newbies to some important EA perspectives and does help with common terms and concepts, but it requires a lot of additional buddy-work with an experienced architect to become useful and, what’s worse, it conveys the wrong message; ‘Enterprise Architecture is complicated and requires a high intellectual capacity to understand’. The latter being the absolute opposite of what I need to convey across IT and the business; ‘Enterprise Architecture is about joining-the-dots and making things simpler to understand’.

I do continue to put my team through TOGAF Certification. Why? It’s the only credible option here getting newbies up-to-speed on the basics of EA/SA and it helps my staff build their CVs (which is important). I just wish there was a better option that was both less and more:



and


  • more – on the basic mentality required of of an EA (e.g ability to abstract) and why all organizations take a different approach to architecture based on culture, maturity and business priorities.

I sometimes wonder if the authors of TOGAF are motivated to make it more understandable, or, as seems to be the case, keep it obscure and arcane. It certainly felt that way when I was exposed to IAF (Capgemini’s Framework) and its zealots for the first time.

An aside here: in a recent chat with the Chief Architect in a well-known travel company, I said I needed the 80 page version of TOGAF – he laughed and responded that he’d implemented an 8 page version! BTW: all his architects are native-English speakers hired in from abroad.