Guest Post by Ray Hearrell

The #NoEstimates debate has struck a nerve with the software development community. The #NoEstimates movement is about exploring alternatives to estimates (including cost, time, and effort) for making decisions in the software development life cycle. Should your team say “yes” to #NoEstimates? Let’s explore the pros and cons.

The traditional approach of software development estimating focuses on:

• Taking the highest priority planned work
• Slicing work into risk-neutral stories
• Committing specific scope to sprints based on various estimation methods

These methods may include relative and T-shirt sizing, user story sizing based on Fibonacci sequence, poker planning, triangulation to validate estimates, and ideal time.

The idea behind the #NoEstimates movement is to allow professionals, specifically those in the software industry, to work incrementally and reach a desired shippable product as rapidly as possible. The movement does not focus on removing estimation from agile; it is about exploring alternative ways of planning work, assigning value, and a different approach to how and what we deliver to our clients.

As with anything, there are benefits and drawbacks to the #NoEstimates method, some of which include:

Pros of #NoEstimates:

• Saves time and effort spent on estimation at a program and release level. At the sprint level, the team commits to a number of stories to track throughput.
• Allows scrum team to focus on researching a viable solution by taking away timeline-driven approach. When using estimates and velocity as planning tools, there is an inherent assumption about achievements in a given period.
• Increases delivery team satisfaction by removing the pressure of time-based approaches.
• Conducive to niche environments that thrive on creativity

Cons of #NoEstimates:

• Impacts ability to manage key decision-making business stakeholders who are accustomed to estimation, especially for forecasting and budgets. High-level planning and estimation (which is about delivering a pre-defined pre-prioritized product backlog) is contrary to the iterative/holistic #NoEstimates approach.
• Not conducive to enterprise/large-scale strategic initiatives that drive business value.
• Limits the ability to develop integrated strategic delivery and business readiness plans for large enterprises.

The #NoEstimates approach enables developers in small companies to thrive in a constantly changing environment. However, large companies may find it difficult to align upstream and downstream business and technology teams. Therefore, for companies with a focus on shareholder value, large strategic programs and return on investment, we recommend using lean estimation practices and proven agile planning methodologies that enable organizations to balance delivering business value by adapting to change.

Where do you stand on the #NoEstimates debate?

Image shared by János Balázs

Link: http://intellyx.com/2014/12/16/digital-transformation-self-organization-paradox/

The transformation in digital transformation connotes an enterprise-wide organizational change, centering on the facilitation of self-organizing, innovative digital teams. Managers intent on achieving such self-organization, however, face a paradox: self-organization suggests the absence of management, so what’s a manager to do?

Scenario: Self-Organization Gone Wrong

Bob, your VP of Engineering, brings a ScrumMaster, a Java developer, a UX (user experience) specialist, and a Linux admin into his office. “We need to build this digital widget app,” he says, describing what a product manager told him she wanted. “So go ahead and self-organize.”

Bob’s intentions are good, right? After all, Agile teams are supposed to be self-organizing. Instead of giving the team specific directions, he laid out the general goal and then asked the team to organize themselves in order to achieve the goal. What could be more Agile than that?

Do you see the problem yet? Let’s shed a bit more light by snooping on the next meeting.

The four techies move to a conference room. The ScrumMaster says, “I’m here to make sure you have what you need, and to mentor you as needed. But you three have to self-organize.”

The other three look at each other. “Uh, I guess I’ll be the Java developer,” the Java developer says.

“I’ll be responsible for the user interface,” the UX person says.

“I guess I’ll be responsible for ops,” the admin volunteers.

Excellent! The team is now self-organized!

What’s wrong with this picture, of course, is that given the size of the team, the constraints of the self-organization were so narrow that there was really no organization to be done, self or not.

And while this situation is an overly simplistic example, virtually all self-organizing teams, especially in the enterprise context, have so many explicit and implicit constraints placed upon them that their ability to self-organize is quite limited.

As a result, the benefits the overall digital effort can ever expect to get from such self-organization is paltry at best.

Read the rest of the article at http://www.forbes.com/sites/jasonbloomberg/2014/12/16/digital-transformation-self-organization-paradox/.

Intellyx advises companies on their digital transformation initiatives and helps vendors communicate their agility stories. As of the time of writing, none of the organizations mentioned in this article are Intellyx customers. Image credit: Vincent Diamante.

Link: https://enklare.wordpress.com/2014/12/31/the-change-canvas/

As a teaser for the new year I thought I’d release The Change Canvas (TCC). Much more to come on this and related topics during 2015.

The Change Canvas

The Change Canvas 2015 – Click image to view powerpoint presentation on Slideshare

License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

Link: https://enklare.wordpress.com/2015/01/02/the-brand-canvas/

Designing and understanding brands and how the behave as figments of their own is hard enough. Having a simple structure that one can use to design and / or understand a brand makes designing businesses so much easier. More details to come on this topic…

The Brand Canvas

The Brand Canvas 2015 – Click image to view powerpoint presentation on Slideshare

License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

Link: http://davidsprottsblog.blogspot.com/2015/01/understanding-agile-adoption-failure.html

The most common concern our customers voiced in 2014 was the unexpected outcomes of Agile projects. They don’t talk about failure as such. But they do talk about loss of consistency; inability to govern; lack of coordination AND THE INCREASING TIME TO MARKET caused by these precise issues.

I was struck by the results of the Agile Adoption Experiences Survey 2014 published by Scott Ambler. The really significant result to me is that 40% of respondents rates their organizations adoption of Agile as neither a success or a failure. Add to this the categories of Failure, Great Failure and Too early to tell and you have 58% that are not successful! This synchs with my customer feedback referred to above.

The advice my colleagues and I give when customers approach us looking for answers to these questions, is to look at how architecture is integrated into Agile projects. And there are some key areas that we look for in our assessments:
1. Is there a good reference architecture and associated contextual patterns?
2. Are there clear policies attached to work products together with the rationale?
3. Are developers and architects working as a community of interest to evolve the reference architecture, patterns and policies?
4. Are the reference architecture, patterns and policies integrated into the tooling and the architecture runway?
5. Is the architecture runway model based – allowing it to provide a reusable design time platform to be evolved by projects?

Agile projects can be successful in an enterprise situation. But architecture and governance need to be coordinated for consistency and mechanisms (automation) enforced to ensure consistency.

I wonder why the Agile Adoption survey didn’t ask any questions along these lines?

Link: https://enklare.wordpress.com/2015/01/07/the-capability-canvas/

Designing businesses is not a trivial activity. Having a simple structure that one can use to design and / or understand a capability makes designing business architecture so much easier.

More to come on this topic during 2015.

The Capability Canvas

The Capability Canvas 2015. Click image to view powerpoint presentation on Slideshare

License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

Link: https://enklare.wordpress.com/2015/02/09/on-business-capabilities-functions-and-application-features/

Working with architecture as a way of designing and cataloging the relationships between business and IT has always been a challenge. I recently attended an IASA meeting where we discussed the challenges of designing and maintaining a business architecture. At the meeting I talked about capabilities, what I think they are and how to actually go about identifying the key set of capabilities in a business. I also talked about my view of how these capabilities relate to other elements of an architecture. My view is as I’ve understood a bit different from the common view amongst architects. I promised the participants that I’d release some of my writings on this topic, so here is a preview of the work I’m doing right now.

The basic assumption I work from is that one should try not to confuse functions (functionalities of a business) with capabilities. If one take a good look at the way I prefer to design the connection between information systems and the business one would see that there are no “functions as capabilities” in that architecture.

Functions are a really good way of structuring one view of the architecture but it is not the same as my view of capabilities. Functions are easy to break down in an hierarchical architecture that can serve as excellent requirements of an IT-architecture, if you pare it with a service architecture it’s even better. The best way of doing this functional break down that I’ve seen so far is by Cutter Consortium and it’s documented in the article “The Business Capability Map: The “Rosetta Stone” of Business/IT Alignment“. The functional maps can easily be created for a whole business, a segment or some other subset. One really good thing with them is that if you have excellent architects and knowledgeable subject matter experts then you can start in any corner of the white space and flesh out the map as the projects comes along. I’ve done a lot of these types of maps for various businesses and in my mind they are essentially functional maps and not capability maps. Rest assured that the maps alla Cutter Consortium are effective and brings with them great value, however I believe there is an even greater value to be gained from creating another type of capability maps.

The capability map I describe is on the other hand not used on anything but the business as a whole, and they don’t break down hierarchically.

I’m in the process of creating my complete writings on this topic so here is a draft of a sample capability map. Each one of these capabilities I would detail using The Capability Canvas.

When you should use this

• When figuring out what capabilities to grow as described in this McKinsey report: Building capabilities for performance
• When designing the business architecture and it’s relationship with information systems.

License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

You can download the slides from slideshare here.

Change log
2015-06

Added the initial post and three images of the slide package from the up and coming courseware.

2015-09

Moved the article from a page format to a post format.

Rewrote some text and also rearranged some of the text.

Link: http://intellyx.com/2015/02/19/jason-bloomberg-to-speak-at-the-informationweek-devops-virtual-summit/

This virtual event puts you in direct contact with experts and leaders in the DevOps space, including noted speakers from InformationWeek, Gartner, Intellyx and CA Technologies — all without ever having to leave your seat! Learn best practice approaches for DevOps in areas of agile development, continuous delivery, and agile IT operations, and watch an inspiring keynote from Gene Kim, the “Father of DevOps.”

March 18, 2015, starting at 12:00 EST. Click here to register.

Featured Speakers:

 

Gene Kim Author, Researcher, Speaker, Director, DevOps Enthusiast	Eric Bruno Contributing Editor InformationWeek	Aruna Ravichandran VP, DevOps Product & Solutions Marketing CA Technologies
Jason Bloomberg President Intellyx	Andi Mann VP – Products, Strategy, and Marketing: Office of the CTO CA Technologies	Adam Mills Senior Manager of Automation AutoTrader.com

#DevOps2015

Link: http://intellyx.com/2015/03/16/agile-and-safe-in-gov-progress/

Jason Bloomberg, a leading industry analyst who writes for Wired and Forbes, and how has interviewed us in the past, (see The Battle of the Agile Curmudgeons? Forbes on SAFe) has been covering a subject to which we’re all paying very close attention: Agile in Government.

He recently wrote about advancements made with Agile approaches in one of the most problem-plagued agencies, the VA Administration. But this is as part of a much larger story, which is how scaled Agile is fast becoming a common approach across the entire US federal government. We are now seeing SAFe used in multiple agencies (Commerce, Justice, DHS, NGA, Navy, NASA, and a few more that we are aware of; not sure if it is play at the VA). At least one or two case studies are in progress for eventual publication here.

Read the entire article at http://www.safe30.com/agile-and-safe-in-gov-progress/.

Link: http://feedproxy.google.com/~r/Soapbox/~3/fQgzm-gXID4/ruthmalan-challenges-swardley-on-agile.html

@ruthmalan challenges @swardley on #Agile

Asked what is agile? It’s a method of reducing the cost of change when developing an uncertain act.
— swardley (@swardley) April 21, 2015

@swardley have you seen John Seddon’s quip: “Waterfall: doing the wrong thing righter. Agile: doing the wrong thing faster.”?
— ruth malan (@ruthmalan) April 21, 2015

@swardley in theory What we’re paying attention to shapes what we perceive and pay attention to. etc.
— ruth malan (@ruthmalan) April 21, 2015

@swardley I was making a sophisticated/nuanced point. We canalize — we think we’re open to finding misdirection but it’s hard
— ruth malan (@ruthmalan) April 21, 2015

Let’s suppose Agile developers know how to optimize some of the aspects of a system, perhaps including skin and services. So it doesn’t matter if they get the skin and services wrong, because these can be changed later. This is the basic for @swardley’s point that you don’t need to know beforehand exactly what you are building.

But if they get the fundamentals wrong, such as site and structure, these are more difficult to change later. This is the basis for John Seddon’s point that Agile may simply build the wrong things faster.

And this is where @ruthmalan takes the argument to the next level. Because Agile developers are paying attention to the things they know how to change (skin, services), they may fail to pay attention to the things they don’t know how to change (site, structure). So they can throw themselves into refining and improving a system until it looks satisfactory (in their eyes), without ever seeing that it’s the wrong system in the wrong place.

One important function of architecture is to pay attention to the things that other people (such as developers) may miss – perhaps as a result of different scope or perspective or time horizon. In particular, architecture needs to pay attention to the things that are going to be most difficult or expensive to change, or that may affect the lifetime cost of some system. In other words, strategic risk. See my earlier post A Cautionary Tale (October 2012).

Link: http://it.toolbox.com/blogs/ea-matters/agile-versus-architecture--66420?rss=1

Agile and Architecture seemed to be, rightly or wrongly, often discussed together today. Should Enterprise Architecture be Agile? This is the question we all ask in fact.

Let’s go back to basics.

Agile is the developer’s way to do more work with less management, something around the 8

Link: https://enklare.wordpress.com/2015/04/26/the-scenario-canvas/

This little canvas is part of my toolbox for detailing and documenting scenarios.

The Scenario Canvas

Note: I’m currently in a process of changing my presentation design (the image shows what the new design looks like) for all my work. When I’ve stabilized the design and applied it across all canvases and related material I’ll link up the powerpoint to Slideshare.

When you should use this

• When designing target architectures I tend to use scenarios in conjunction with capabilities to help navigate the uncertainties of the future. (How this is done will be covered in a later post)
• In the HBR article Living in the futures, Angela Wilkinson and Roger Kupers highlight how Shell has used scenarios.
• In the McKinsey article The use and abuse of scenarios, Charles Roxburgh highlights some great insights into when and how to work with scenarios.
• In the Forbes article Scenario planning and strategic forecasting, Jan Ogilwy presents a way of doing scenarios and also an interesting graph on what tools people use to peak into the future.

License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

Post change log
2015-04-26: Published initial post

Link: http://blog.opengroup.org/2015/04/27/agile-enterprise-architecture-a-good-to-great-evolution/

By Priya Patra, Sr. Manager at IGATE Global Solutions I have been an Agile Practitioner for years now, have been in many successful Agile executed projects. But as an Enterprise Architect I am somewhat skeptical about the fact how the … Continue reading →

Link: https://enklare.wordpress.com/2015/05/11/the-strategy-model/

This model is part of my toolbox for working with strategic architectures.

The Strategy Model

Note: I’m currently in a process of changing my presentation design (the image shows what the new design looks like) for all my work. When I’ve stabilized the design and applied it across all canvases and related material I’ll link up the powerpoint to Slideshare.

When you should use this

• Whenever you set about understanding the greater enterprise

License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

Post change log
2015-05-12: Published initial post

Link: https://enklare.wordpress.com/2015/05/19/the-inventory-model/

This model is part of my toolbox for working with business architectures.

The Inventory Model

The important thing to remember is to be agile minded in use of tools like this. So, when I say extendable I mean that this is definitely not all things that could or should be in the inventory. Reconfigure it in the X, Y or Z axis as you see fit for purpose and make sure to deliver something of value.

Note: I’m currently in a process of changing my presentation design (the image shows what the new design looks like) for all my work. When I’ve stabilized the design and applied it across all canvases and related material I’ll link up the powerpoint to Slideshare.

When you should use this

• Whenever you set about depicting the greater enterprise

License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

Post change log
2015-05-19: Published initial post

Link: https://enklare.wordpress.com/2015/06/15/the-capability-inventory/

This model is part of my toolbox for working with capability architectures.

The Capability Inventory

I know that there is certain ways of naming a capability and also that there are other principles that people and I promote that you should adhere to when designing your capability map. Here I’ve taken some liberties in regards to those principles to make it easier to relate to the possible content in the boxes. This inventory is basically what I refer to as “functions as capabilities“, now there is certainly a way of mapping proper capabilities into this inventory.

Download note: I’m currently in a process of changing my presentation design (the image shows what the new design looks like) for all my work. When I’ve stabilized the design and applied it across all canvases and related material I’ll link up the powerpoint to Slideshare.

When you should use this

• Whenever you set about designing a capability model of your enterprise
• When you need to understand what types of capabilities an enterprise can have

What you should consider when you use this

• This is not “the complete or correct” inventory of capabilities
• There is no known right way of designing or describing a capability of an enterprise
• There is techniques like reversing the names of processes and then consolidating them that could give you a fair hint of what capabilities you have in your enterprise
• Look at other peoples capability inventories and take inspiration from those
• The “best” capability inventory is the one you get enough people to use in their work
• Develop the capabilities and the capability inventory in as wide spread community as possible
• Continuously refine your capability inventory as you go
• In the end it’s all about just doing it

License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

Related

• The Capability Canvas

Post change log
2015-06-15: Published initial post

Link: https://enklare.wordpress.com/2015/06/30/capability-architecture-and-microservices/

The Elements of a Capability Model

The capability model could contain a lot of different elements but the basic ones are:

• The Capability Areas which serve as a reflection of the functionality needed to run the business.
• The Capability Groups which serve as blueprints for responsibility.
• The Business Capabilities which serve as blueprints for business services.
• The Resource Capabilities which serve as blueprints for microservices.

Frequently I use the capability model to project other elements on it. A very useful projection is visualizing the information ownership (entity groups, entities and sometimes even attributes) and the information responsibilities (business objects).

The Capability Information Model

The model below is an example showing ownership of information from a capability perspective. The model is the same as the one further down but it is focused on showing what information a capability group is the owner of.

Zooming into one of the capability groups (claim settlement management) we see that it contains information elements.

The Capability Collaboration Model

The model does not show every business object needed or created by the business capabilities, this is by choice. The  aim here is to show what a capability collaboration model looks like. The main objective on a capability collaboration model is to show the information responsibilities.

Whenever you start to develop a capability architecture you will soon need to verify that the boundaries are where they should be.

How to build the model

1. Start by taking one of the business capabilities and look at what information it need that it doesn’t have in it´s own context. The business capability will need this information to do it´s work and to generate the outputs it is responsible for, as a result you get business object candidates.
2. Assign the business object you´ve identified to the one business capability that would generate it.
3. Draw an arrow from the providing business capability through the business object ending up on the consuming business capability.
4. Continue with tying the string between every other business capability that you found. Follow the steps 1, 2, 3 and 4 until you´ve exhausted all identified capabilities.

Rules of thumb

If you find business objects appearing out of nowhere then it is a fair assumption that either the consuming business capability is wrongly specified or there is a providing business capability that has not been identified yet.

If there is reason for it then you should include business capabilities that belongs outside of your corporate context.

A definition of a business object

A business object is defined as a specifik set of entities representing the total amount of information needed by one business capability from one other business capability.

Business object is part of the information domain in the Inventory Model (EA framework).

When you should use this

• Whenever you set about designing a capability model of your enterprise
• When you are set to create a target context map for microservice architectures

What you should consider when you view this

• This is not “the complete, nor may it be the correct” capabilities of any specific insurance company
• Continuously refine your capabilities as you go
• When naming capabilities think of each capability as part of a namespace
• In the end it’s all about just doing it

Other things to consider from a capability model

The organizational perspective

• If you work in an agile inspired environment the the capability groups gives guidance to where product managers would be responsible.
• Teams should be set out to take responsibility for governing the business services realizing business capabilities.

The service perspective

• The only way to access information governed by a capability group is through the business capabilities inside.
• Each capability group is the sole provider of it´s business objects.

The realization perspective

Realizing a capability architecture can be done in many ways.

• The monolith pattern would use the capability areas as system boundaries and capability groups would then be represented by subsystems.
• The service pattern would use the capability areas as knowledge boundaries and capability groups as information boundaries. Business capabilities would be used to orchestrate access to sets of microservices (resource capabilities).

License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

Related

• The Capability Canvas (local link)
• The Capability Inventory (local link)
• Other ways of thinking about capabilities (local link)
• Microservice Principles and Enterprise IT Architecture (external link)
• Microservices Are SOLID (external link)

Download note:

I’m currently in a process of changing my presentation design (the images shows what the new design looks like) for all my work. When I’ve stabilized the design and applied it across all canvases and related material I’ll link up the powerpoint to Slideshare.

Post change log
2015-06-30: Published initial post

Link: https://enklare.wordpress.com/2015/07/02/using-the-capability-inventory-for-municipalities/

Using the Capability Inventory for municipalities

I was talking to Marino the other day and he told me he would like a special capability inventory for a municipality. I said that there is no need to have a special capability inventory, the basic pattern exposed in the original capability inventory should cover any organization. In fact he should just use the original one and perhaps add the elements that are missing.

The basic pattern behind the capability inventory is to view every organizations output as delivering services. This view enables us to use the same basic elements across all organizations. I can relate to the fact that the pattern and elements looks unfamiliar because it does not follow the way one is used to visualize a municipality. To remedy any confusions I´ve designed a naïve example below.

In the example I´ve removed the elements in the envision and enable rows and focused on the engage row. The text in the capability elements are not capabilities rather they descibe the activities one would perform using the capability to reach the business goals.

When you should use this

• Whenever you set about using a capability model of your enterprise
• Whenever you have a new business problem to consider

What you should consider when you use this

• Using the capability inventory and mapping out the basic activities will give you a good hunch but it is not the complete constructs needed to design the business.
• It took me about 15 minutes to whip up the example

Download note

I’m currently in a process of changing my presentation design (the images shows what the new design looks like) for all my work. When I’ve stabilized the design and applied it across all canvases and related material I’ll link up the powerpoint to Slideshare.

License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

Related

• The Capability Inventory (local link)
• The Capability Canvas (local link)

Post change log
2015-07-02: Published initial post

Link: https://enklare.wordpress.com/2015/07/10/event-based-processing-and-capability-architecture/

The illusions of process architectures

Most of the time people expect that a process is a linear execution of activities that has been predetermined, some people call this the happy path (top illustration) and expect that this is the way things should work. On other occasions people realize that processing is a bit more complex and adds in what they see as the alternative routes a process can take (middle illustration). These two views of processing is how almost all process architectures are expressed. In reality though processing from a business perspective is a jumble of alternative paths (bottom illustration) and it’s all but impossible to know before hand what the process would look like.

Sisney (2012, l. 1406) writes that `adaptation to the environment is supreme and fitness or capability is always secondary´. This fits well with my view on the notion of dynamic processing and agile businesses.

Bloomberg (2013, p. 101) writes that `the end results are dynamic processes that have no predetermined flow. Instead, the people involved in the process begin with the goal for the process and then the technology supports the interactions among the people in order to achieve the goal´. This fits well with my assumption about processing as only dynamic activities that have no predetermined flow.

The traditional process view on a business solution architecture

This is the way most process views are expressed and it sucks. It sucks because it forces the business to become stale. It sucks because it forces the information systems into rigidity and complexity. After a couple of months or years people find new ways of working and there will be variations to the services offered. At that time it will become increasingly difficult to make changes in the systems and the business will suffer. The lead time from idea to realization will be longer and longer and complexity will increase until the system collapses under its own weight.

However it is not all bad with the traditional way of doing process architectures. Considering the fact that the same activities could be activated in the same order repeatedly we would leave tracks in our logs. Those tracks we could refer to as processes. By stitching those processes together we could use them as generic processing patterns, which would enhance our understanding of the overall behavior. From a systems execution standpoint tracks would enable us to reach higher performance, since we would not have to start from scratch all the time.

Agile processing view on a business solution architecture

Richards (2015) writes that `Claims processing is a very complicated process. Each state has different rules and regulations for what is and isn’t allowed in an insurance claim. For example, some states allow free windshield replacement if your windshield is damaged by a rock, whereas other states do not. This creates an almost infinite set of conditions for a standard claims process´. The complications on process variations that Mark bring to light in his book is one reason why going to a capability based microservice architecture is the right thing to do for many information systems.

The processing dimension depicted in the illustration below is to be considered as a generic processing pattern. If you where to interview a business expert this is how you like them to describe their work. Knowing this we could start asking the business expert for each activity what it really is they would like to achieve by performing that particular activity. The result from such an inquiry would be activity goals, these goals we could express in the architecture as activity events. If we did this transformation from activity goals to events we lay the foundation for freedom in processing and retain the ability to continue our conversation with the business experts.

The illustration above is a good representation of how I would recommend expressing parts of a business solution architecture. This way ensures that the architecture is future-proofed for the business and at the same time able to realize the promise of agility and scalability through digitization.

The event hierarchy is the foundation for dynamic processing

Events map naturally to capabilities and activities which gives us the guidance needed to allow the users infinite ways of executing a generic processing pattern. If we then choose to implement this business solution architecture as an event based software architecture we can support the users no matter how they choose to work as long as they satisfy the goals in the activity events.

The Elements of an event based goal model

• The Market Events serve as a reflection of the goal a customer seek from interacting with the business.
• The Business Events serve as a reflection of the goal a business seek from interacting with the customer.
• The Activity Events serve as a reflection of the goal a role seek from interacting within the servicing of a business event.
• The Transaction Events serve as a reflection of the goal an actor seek from interacting within the servicing of an activity event.

When you should use this

• When business requires future-proofing the support they get from information systems
• When you consider moving to an agile enterprise architecture
• When you are set to create a microservice architecture

What you should consider when you view this

• This is not “the complete, nor may it be the correct” views of any specific insurance company architecture
• Continuously refine your events as you go down the capability hierarchy
• When naming events think of each event as the goal to be achieved
• In the end it’s all about just doing it

Related

• Capability architecture and microservices (local link)
• The Capability Canvas (local link)
• The Capability Inventory (local link)

Reference list

• Sisney, L. (2012). Organizational Physics | The Science of Growing a Business.:.
• Bloomberg, J (2013). The Agile Architecture Revolution: How Cloud Computing, REST-Based SOA, and Mobile Computing Are Changing Enterprise IT.:.
• Richards, M. (2015). Software Architecture Patterns. Retrieved from http://www.oreilly.com/programming/free/files/software-architecture-patterns.pdf

Download note:

I’m currently in a process of changing my presentation design (the images shows what the new design looks like) for all my work. When I’ve stabilized the design and applied it across all canvases and related material I’ll link up the powerpoint to Slideshare.

Post change log
2015-07-10: Published initial post

Link: http://intellyx.com/2015/08/01/is-agile-killing-enterprise-architecture-the-digital-transformer/

By Charles Betz

The relationship of Enterprise Architecture (EA) to the Agile movement has been a topic since the earliest days of Agile, with Scott Ambler being a notable pioneer. More recently, Jason Bloomberg has questioned “Is Enterprise Architecture Completely Broken?” and discussed Agile EA at Netflix with the notable Adrian Cockcroft.

Various authors advocate that practices like iteration, Scrum, incremental delivery, and DevOps be combined with enterprise architecture, but I think that some of these discussions are superficial. In light of the current challenges, we need to have a deeper understanding of what EA does and how it adds value. Yes, you CAN weave EA into an Agile delivery stream. But why SHOULD you?

Read the entire article at http://tdan.com/the-digital-transformer/18573.