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

GLUE Value Add

By looking at the GLUE Disciplines and how to GLUE Disseases one of my main goals is always to optimize the flow of information and reduce waste. Which brought the idea behind this post onto the surface of my thinking.

“Short as life is, we make it still shorter by the careless waste of time”,
Victor Hugo (1802 – 1885)


So what is waste in GLUE. How to find waste and how to eliminate or at least minimize it. The GLUE Disciplines play a major role here, because they are motivating the action to deliver a solution.

  • Describe Intention does not add value. The pure description of the intention does not give any further value to the existing solution. It might guide towards a future state of the solution. The interesting thing about Describe Intention to me is that many investments are made based on a fuzzy statement about a potential To-Be future. As stated in Enterprise Architecting Past, Future or Present I do not believe that the future is really truly predicable, so good luck with your investment bet.
  • Define Requirements does not add value. The definition of the requirements does not give any further value to the existing solution. It might give a fairly good picture on how a potential future of the solution can look like. The interesting thing about Define Requirements to me is that many decisions are made based on requirements as if they are facts.
  • Design Architecture does not add value. The organization of requirements into elements does not give any further value to the existing solution. It might provide a reasonable split between the elements and might order and organize them. The interesting thing about Design Architecture to me is that many architecture To-Be documents are treated as if the problem is already solved.
  • Develop Solution adds value. Here something is added to an existing solution and therefore adds value to the existing. (under the assumption that it was done in an educated and careful way).
  • Do Operation does not add value. Running any solution does not add value, but only supports in keeping the existing value alive. The interesting thing about Do Operate to me is that there is quite often the believe that execution excellence (Do Operate) adds value, even though it only maintains the current.
  • Detect on Solution does not add value. Inspecting if an solution is fit for purpose does not add value, but only checks if value was delivered or the execution is still done in the right way. The interesting thing about Detect to me is that quite often a high maturity assessment results leads to the believe that a solution is excellent.

So the real value add inside the GLUE model is only on the Develop Discipline:


So why are we doing all these activities. Reality is that we have to take into account the persons who do the activities and in most cases people can not (or are not allowed to) see the full holistic picture of the solution.


But in a total idealistic world or an GLUE Utopia the only really needed deliverable would be based on Development activities. In this case no waste would be generated and all time spend would be dedicated to the development of the existing solution. So when I look at any given method or tool at hand I try to find one which is minimizing on waste and I try to only generate the waste I absolutely must generate. Being an Enterprise Architect myself there is quite some waste I could generate for the only real value add which is Development:


I am happy to hear about your thoughts and comments.

Categories Uncategorized Tags