#eavoices

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.

Welcome to my blog!

by

Welcome to my blog!
I am very excited about the new developments in The Zachman Framework 3.0 and Zachman International! We have spent the last couple years “underground” refining our research, developing several new programs, forging new relations…

Work from home and making adult choices

by

My friend and colleague Jack Santos sent me a link to the NYTimes story “Looking for a lesson in Google’s Perks” by James B. Stewart. Jack knows I am interested in work from home and anything else for that matter related to employee engagement. The article states that “Google doesn’t require employees to work from […]

The post Work from home and making adult choices appeared first on Mike Rollings.

An Agile Enterprise Architecture (EA) Delivers Critical Business and Mission Agility

by

While working with a recent partner, the question came up; “What changes are made to the EA approach if agile methods are required, or otherwise heavily encouraged?” The initial answer at the time was “Not many – we already have an agile approach to EA embedded in our Oracle Enterprise Architecture Development Process (OADP), and our Oracle Enterprise Architecture Framework (OEAF) is independent of project management and project development approaches.”

Our OADP has always been agile and therefore supportive of business and government agility – particularly in the current context of severely constrained budgeting cycles. We firmly believe in a “just enough, just in time” philosophy, with collaborative insight and contribution across teams and leadership, and delivery of EA artifacts or guidance tuned directly to prioritized results. This means strategic, useful and reusable guidance modeled and delivered in a manner that supports both longer-term initiatives and near-term objectives.

EA delivered as an agile approach, however, does require continual line-of-sight traceability back to the IT investment strategy – which in turn is aligned to the business strategy.  

In other words, a Sprint Iteration approach might be justified (i.e. using the “Scrum” strategy), from all relevant perspectives, to quickly establish a reusable process and metadata model for a common agency function – like “Document Routing and Approval” (DRA). The output might be required to inform a software solicitation (i.e. to explain the requirements).  The output might be to establish a reference model and basic governance (business rules) for identifying and improving process efficiencies around the agency where DRA is occurring.

The actual need for this EA artifact (or “Product”, in Agile terms) may be driven from an unanticipated mandate or regulatory change, and therefore require rapid response.  The need may also be limited in scope to only a portion of the agency’s business (i.e. those who actually know they need it).

So, an EA Sprint will work, and deliver what’s needed quickly and effectively to the target audience.  The highest return on investment (ROI) in this exercise, however, only exists if actual Enterprise traceability and impact assessment occurs. In other words, an agile EA output with a strategic Enterprise outcome.

Note this is a common misunderstanding for Agile software development; Agile programming and project management may deliver useful, rapid and cost-effective “features” from a Backlog of priorities, but much of the supporting infrastructure, integrations and organizational change isn’t delivered using Agile methods, but must evolve in a more strategic, methodic manner.  Preferably with EA guidance.

Here’s what should happen.  The common DRA process, metamodel and business rules begin to shape, in a somewhat parochial “requirements-driven” context, heavily leveraging the impacted SMEs for a short period of time. As this occurs, the Enterprise Architect and stakeholders begin mapping and comparing the DRA process design (at appropriately coarse levels of abstraction) to any similar that may exist within the agency, or among agency partners or stakeholders.  This may require some additional outreach and communication.  The EA may find additional SMEs, risk factors, standards, COTS DRA solution accelerators, overlapping data management projects, etc. – essentially other activities or resources that can be used or might be impacted.

The Enterprise Architect is the Scrum Master!

Strategic oversight and influence is therefore brought to bear on the EA sprint, and by leveraging EA methods, the impacts to the rest of the organization plus any modifications to the focus EA artifact can be addressed – entirely within standard and expected IT Governance. The EA artifact development is a Sprint, but actually leverages our lifecycle methodology – from Business Context through Current and Future States, and then Roadmap (i.e. Transitional Architecture) and Governance.  The EA Sprint may actually kick off or modify a more holistic EA maintenance process.

We are therefore avoiding an “agile everything” philosophy, though we’re delivering agile results.   We contribute over-arching guidance and process for both the DRA project and the organization as a whole, to make sure that all projects underway are still aligned to meet the needs of the business and IT investment constraints.

This is essentially what we believe in applying our EA process, over time or during more Agile response cycles; always raise and maintain focus on the business strategy and drivers to guide the investment of IT budget into those areas that affect the business most – or that are the most immediate priority, such as described above.

Thanks to Oracle Public Sector Enterprise Architect Ted McLaughlan for contributing to this article!