A matter of perspective

It has been a while since my last post about Value Creation and GLUE. Interesting enough this created some discussions via twitter about what is a real value add and what not. I still stick to my statements that the only value add is located in the GLUE Discipline Develop and methods and tools to be able to deliver real value are not value in itself (despite the moment when they are created and/or added to an environment).

“The world is given to me only once, not one existing and one perceived. Subject and object are only one.”,
Erwin Schrödinger (1887 – 1961)

The interesting challenge I personally observe in Enterprise Architecture each and every day is to ensure that the existing and perceived world are synchronized to be recognized as the same. On top of that the IT world has created another challenge which now requires that the existing world, the artificial reflection of the world, the perceived existing world and the perceived artificial reflection of hte world needs to be synchronized. As I have written in “Always remember the next larger context” the challenge is to find the one-to-many mapping in the GLUE Space to ensure an accurate artificial reflection of the world and therefore synchronize the real world with the artificial world.

Imagine a company which is multinational and organized with a global, regional and local organizational setup. To keep it simple the artificial reflection of the world could be done by harmonizing all processes in the world and deliver a one size fits all approach:


In most situations this is a fairly good marketing statement and looks very good to justify huge initiatives to align processes around the world. The pushback of the real world is most likely enormeous and depending on the size of the company and the diversity of the markets there is literally no chance to squeeze the whole into the same concept. But maybe a regionalized approach does work where there is one process fits all for one region approach:


This will give a fairly large amount of alignment but at the same moment in time neglects the necissity for local deviations and specialities of single elements in a corporation. This can be fairly simple reasons like local legal law or more complex reasons like a different approach to the market, because the market situation is different in that specific country and legal entity. Therefore the answer can easily look fairly diversified:






So in many cases the final architecture will be federated. No matter if it was a structured educated approach to reach a federated architecture or evolution over time due to created necessity by restructuring the organization and therefore creating the implicit demand for a federated architecture (Conway’s Law). The end result (from a conceptual point of view) is the same. A mixture of Global, Regional and Local elements:





The interesting thing from an Enterprise Architecture point of view to me now is the perspective in such an architecture. It might be very interesting to find the right federated architecture, but I believe it is not really relevant. Relevant is to help the people who must live and work in such a federated architecture to see the whole holistic view. So in the discussion between a global and a local owner the tension between the two perspectives is fairly easy to observe. From the global point of view the local part of the architecture is just another Customer which of course has to follow all rules and boundaries of the global architecture:




From a Local point of view the Global System is just another part of the architecture in the complete holistic local architecture. The business case for success for the local part of the corporation is in most cases motivated by local demand and conflicting with global demand.



The interesting discussion now is to find the right federated architecture. Unfortunately that is a moving target and does change as fast as the business changes. The discussion about the right To-Be Architecture (even though it indeed is interesting) can easily be an endless ivory tower discussion never coming to a final conclusion. The relevant discussion in my mind is helping all involved stakeholders (and that includes of course the regional elements as well in this example) to see the holistic picture. The real joy of Enterprise Architecture to me is that Enterprise Architects should apply the concept of Schrödinger’s Cat in the Architecture all the time: The Cat is alive and Dead at the same moment in time.

And here (once again) it is more relevant to help the people than to apply a specific method or tool to come to a final recommendation, which I tried to picture in my GLUE framework:


As always questions and comments more than welcome, but I am already happy if you continue to read my blog posts. 🙂


Categories Uncategorized Tags

How the Operating System Got Graphical

In 1995, under the auspices of The Open Group, the Common Desktop Environment (CDE) was developed and licensed for use by HP, IBM, Novell and Sunsoft to make open systems desktop computers as easy to use as PCs. It was the first successful attempt to standardize on a desktop GUI on multiple, competing platforms. The Open Group is now passing the torch to a new CDE community, led by CDE suppliers and users such as Peter Howkins and Jon Trulson. Continue reading

Identity Registries and Reconciliation Posture

A vendor recently asked me a question, and not for the first time, that amounted to “why won’t you buy these delicious software licenses for our amazing identity-management suite, which provides comprehensive solutions to the challenges faced by North American corporations in dealing with compliance requirements and bringing together disconnected versions of identity from across […]

#ogChat Summary – The Future of BYOD

With over 400 tweets flying back and forth, last week’s BYOD Tweet Jam (#ogChat) saw a fast-paced, lively discussion on the future of the BYOD trend and its implications in the enterprise. In case you missed the conversation, here’s a recap of last w…

Agile Enterprise Patterns

Enterprises are grappling with Agile methods- but there’s much to learn. The basic Agile methods don’t cut it in the enterprise. There are many big questions including:

·       What type of projects can use Agile?

·       How do we coordinate dependencies between Agile and non Agile projects?

·       How do we operate in predictive approach for some projects and empirical for others?

·       How do we choose? Who makes that decision and when?

·       How do we integrate Agile projects into all the enterprise frameworks such as enterprise architecture, life cycle infrastructure, inter project coordination, systems development life cycle standards, deliverable standards, asset management, outsourcing and offshore arrangements, contracts and agreements, budgets, and so the list goes on.

·       How do the frameworks need to change?

·       To what extent should we stick to the core Agile methods? Should we allow diversity of method across the teams? Will methodology creep happen anyway, and should we worry?

·       Is progressive Agile adoption a normal capability maturity problem, that needs to be managed?

·       Which resources should be assigned to Agile projects? How do we ensure they are properly skilled? Do we need to assign our best people to Agile, in which case, what risks are we running in non-Agile projects? Where do we find real Product Owners?

By observation, most Agile use in the enterprise is in development. A subset of Scrum with TDD and XP. Or Water-Scrum-Fall as defined by Forrester. In the Agile world, it seems this is a derogatory tag but in the enterprise it’s a pragmatic response, that allows planning and requirements to be executed in a low risk manner, and some key benefits of Agile, to be realized in development.

The Agile community is starting to understand this roadblock. Scott Ambler’s recent book on Disciplined Agile Delivery[i]provides some general advice on scaling Agile, as does Dean Leffingwell’s open framework Scaling Software Agility[ii]. However both of these useful resources address the issue from the Agile perspective, that is extending the management framework a bit, rather than figuring out what the holistic organization needs to do to facilitate effective Agile delivery.  

I argue that architecture patterns are “at least as important as Agile methods” in delivering “business agility”. But equally there are many opportunities to adjust current practice right across the life cycle to complement Agile projects.

The Gartner Group have identified what they call Pattern-Based Strategy, and this seems a useful technique – to provide some structure (as opposed to direction) for a proactive approach to Agile adoption which integrates with the momentum enterprise, right across the life cycle, including as I say agile architecture. By using patterns (and more detailed playbooks), we can guide and coordinate practitioners in all disciplines to engage with agile thinking to find sensible answers. I have set out below my starter list of patterns with a bare minimum of classification.

I note that Schwaber and Sutherland in their excellent book Software in 30 Days[iii], recognize that empirical methods are applicable to any form of project, not just development. They give the example of using Scrum for managing the implementation roadmap of Agile. Perhaps more interesting is the applicability of Kanban, which just may be more enterprise friendly than Scrum, to demand management, architecture, release management etc. Of course it’s important that enterprises and their teams understand and adhere to the fundamental principles of the empirical approach.

Strategy-Based Patterns

Agile EA

Product Definition

Agile Family/Product Line

Water-Scrum

Agile Development

Water-Scrum-Fall

Agile Solution Delivery

Agile KD/MDA/MDD Infrastructure

Service Provisioning

Service Delivery

Service Offering Delivery

Agile Software Factory

Agile Integration

Agile Maintenance

Hybrid Project Delivery


Agile Governance

Management Patterns

Scrum

Kanban

Scrumban

Kaizen

Contract Patterns

Agile Statement of Requirements

Scrum Change Request Protocol

Incremental Delivery Schedule

Definition of Done

Acceptance Protocol

Agile Project Termination

Late Binding Agreement

Target-cost contract

Progressive Contract

Fixed price per Iteration

Fixed price per Story Point

T&M

Shared Risk

Pay per use

Service Level Agreement

Service Specification

Automation Unit Specification

Security Specification


[i] Disciplined Agile Delivery: A Practitioner’s Guide to Agile Software Delivery in the Enterprise,
Scott Ambler
http://www.amazon.co.uk/Disciplined-Agile-Delivery-Practitioners-Enterprise/dp/0132810131

[ii] Scaling Software Agility
http://scalingsoftwareagilityblog.com/

American Idol and Twitter teach us about Elections — active information

In the strange but true category…

“A paper in EPJ Data Science asserts that analysis of social networking data can be used to accurately predict societal events, such as election outcomes. The authors reached this conclusion by studying Twitter activity related to the 11th season of American Idol.”

I wrote about the study in my latest active information post: Can American Idol and Twitter teach us about Elect… – Input Output.

The Architect’s Transformation: From Master Technician to Business Strategist

We are now well into the fourth era of information technology evolution. Along the way IT professionals have been challenged to evolve their skills to keep pace with advancing technology as well as evolving business expectations. Here is my skills view of the architect’s transformation:  Mastery – For the first 25 years of business computing, […]

Pre-Requirement Estimation for IT Projects

Objectives and requirements – they are what makes the project world go ’round. Changing a business’ operations for the better requires one to decide what are the objective of the change, and what are the requirements a change must meet to satisfy the objective. Implementing the change usually starts with someone needing to know what […]

Service, function and capability (an addendum)

How can we clarify the confusion over service, capability and function in enterprise-architecture models? Andrew Marosy made a comment to my previous post on this that really needs to be brought out here in full: You can also visualise a

Service, function and capability (again)

How can we distinguish between service, capability and function in enterprise-architecture models? This is one of those perennial questions that keeps returning time and time again, and it’s one of the key confusions that Enterprise Canvas aims to resolve. But