Aggregated enterprise architecture wisdom
For a start, I sympathise with Tom’s view.Len is quoted to say that “The Open Group and TOGAF will not change their concept of enterprise architecture until the community as a whole does”.I think too that Open Group, as a company, plays an administrati…
Within the world of Agile, architecture often seems misaligned or is a forgotten value-add to a project, especially in enterprise and large scale programs. However, an agile architecture can enable a business to deliver features faster and give them a competitive advantage. Coupled with SaaS and/or Cloud, it seems obvious that agile architectures are required. …
I have now published my book ‘Enterprise Architecture: unlocking business potential’. This publication came about more by accident than design having being encouraged to take the more or less numerous random entries I had made in ‘The Knowledge Economy’ blog … Continue reading →
Chess Grandmasters master the application of concepts and apply them to situations.
I study chess and learn move sequences for Openings, Middle Game, Endings, etc and witness many people get caught up in debates around mov…
This, sadly, is not the blog-post I’d set out to write when I started this brief series. It’s best summed up in just three words: I give up. Seven years ago, I set out to save enterprise-architecture from itself. Who was I…
During October I ran a survey asking Architects, Designers and Project Managers about Service Specification practices. I have just completed the analysis and report, see link below. There are some interesting conclusions:
1. DIY is the dominant service specification approach.
Respondents report there’s a wide range of approaches to service specification in use, and the most common approach by far (50%) is “do it yourself”. Sure, DIY will mean that practitioners are like magpies, they pick up ideas from a variety of sources, and create their own capability. But this, by any measure, must represent a failure of industry standards. While consistency of specification meta data may not be a primary goal for designers and developers, architects should consider a range of risks including use of development automation support tools, standardization of technical components of outsourcing contracts, opportunity to find/reuse pre-existing services, and crucially standardization of tooling. Which takes me onto the next point . . .
2. Documents and Spread-sheets still dominate tool usage for service planning, reporting and management.
In the early stages of service adoption almost everyone simply uses the tools that are available to hand. But as the service portfolio evolves and matures these tools become a strategic liability in areas of planning, reuse management, portfolio and asset management, governance and reporting. I note not one respondent mentioned the EA Repository in context with service support tools. And again this is closely connected with the third interesting conclusion . . .
3. 64% dissatisfied with tool support.
There was a very high level of dissatisfaction with tools, particularly in the context of communicating service specifications between the different roles and groups across the organization. We all appreciate high quality service specifications are the result of multi-disciplinary efforts, spanning Business Analysis, Architecture, Design, Developers, Product Management, IT Service Management, Outsourcing, Procurement, Governance etc . So this is much more than reporting, there’s an evident need for modern tools that facilitate the collaboration process.
During October I ran a survey asking Architects, Designers and Project Managers about Service Specification practices. I have just completed the analysis and report, see link below. There are some interesting conclusions:
1. DIY is the dominant service specification approach.
Respondents report there’s a wide range of approaches to service specification in use, and the most common approach by far (50%) is “do it yourself”. Sure, DIY will mean that practitioners are like magpies, they pick up ideas from a variety of sources, and create their own capability. But this, by any measure, must represent a failure of industry standards. While consistency of specification meta data may not be a primary goal for designers and developers, architects should consider a range of risks including use of development automation support tools, standardization of technical components of outsourcing contracts, opportunity to find/reuse pre-existing services, and crucially standardization of tooling. Which takes me onto the next point . . .
2. Documents and Spread-sheets still dominate tool usage for service planning, reporting and management.
In the early stages of service adoption almost everyone simply uses the tools that are available to hand. But as the service portfolio evolves and matures these tools become a strategic liability in areas of planning, reuse management, portfolio and asset management, governance and reporting. I note not one respondent mentioned the EA Repository in context with service support tools. And again this is closely connected with the third interesting conclusion . . .
3. 64% dissatisfied with tool support.
There was a very high level of dissatisfaction with tools, particularly in the context of communicating service specifications between the different roles and groups across the organization. We all appreciate high quality service specifications are the result of multi-disciplinary efforts, spanning Business Analysis, Architecture, Design, Developers, Product Management, IT Service Management, Outsourcing, Procurement, Governance etc . So this is much more than reporting, there’s an evident need for modern tools that facilitate the collaboration process.
Who defines the profession and disciplines for ‘the architecture of the enterprise’? Who is responsible for it, how, and why? The focus in this part of the series is on a comment by Len Fehskens, on an earlier post about EA and certification. As with the previous post, building on…
Chess Grandmasters master the application of concepts and apply them to situations. I study chess and learn move sequences for Openings, Middle Game, Endings, etc and witness many people get caught up in debates around move sequences. There seem to be endless debates which opening is the best defense for specific offense openings….
Over the last two decades, Lean management has proved to be very powerful in improving an organizations business process performance. During the same time frame, Enterprise Architecture came up as a discipline for controlling the complexity of organiz…
When Darwin wrote his opus magnum On the Origin of Species (Darwin, 1859) he most likely did not have businesses and other enterprises in mind. Yet, the adage survival of the fittest definitely applies to many modern day enterprises. Opportunities and…
I was reading this today: http://it.toolbox.com/blogs/ea-matters/is-there-an-enterprise-architect-paradox-surely-is-57728?rss=1 It is a good analysis of the cognitive dissonance between what Enterprise Architects should be doing and the role and situation they often actually find themselves in. The term Enterprise Architect has been hijacked for far too long. An Enterprise Architect should indeed be a senior leadership role, ideally reporting to […]