Agile or die…

When I posted my previous blog on Aligning ArchiMate to BPMN one of the comments I received read “Agile or die, this is the only fact of today business environment” – and this got me to thinking about Agility in EA.

To be honest, lets start by saying I agree with the comment – and that he gave me no reason to believe the person who posted the comment was misunderstanding anything I said.

But there are those who do…. There’s a stigma sometimes attached to Enterprise Architecture, and architecture as a whole. It’s sometimes seen as slow, synonymous to waterfall, unable to change, and an overhead in general. I will talk about the value of architecture in a separate blog, but suffice to say, architecture doesn’t have to be that way.

Agility in TOGAF

Its fair to say that TOGAF appears to be, or can be fairly document heavy depending on the choices you make in implementing it. A first point to make about TOGAF would be it is a framework that is intended to be tailored to specific needs, and does fit in well with a waterfall development technique; That said it can also provide a good backbone for something more agile.

Everything TOGAF asks for in terms of deliverables within the framework has its purpose. If you take any of those things away you leave a gap or a risk. It’s a comprehensive framework built by many smart people. As a framework it addresses many concerns from different stakeholders.

To be practical you need to think about how to adjust TOGAF. I have sat in a few meetings where we have discussed those different architecture deliverable’s and how we could adapt a Scaled Agile Framework (SAFe) model to work along side TOGAF, giving the strength of TOGAF and the agility of SAFe. It is possible to do so but it requires careful planning & implementation of processes. Processes that are well defined, with good key performance indicators can be very agile.

Architecture Discipline

I firmly believe that good architecture is a key to success in agile ways of working. Agile doesn’t mean we do not do architecture, but it may mean that we do it differently.

If you look at my blog Planning Work With ArchiMate you will see that its possible to use the ArchiMate language to define small building blocks, and then fit them together – each block expressing its own value and interfaces to the world. Although when we use methodologies like SAFe we need to consider the value of each individual work package, we also need to take a longer term strategic perspective. The approach I took in that blog facilitates agile projects as well as waterfall ones.

Change is a constant and enterprise architecture needs to facilitate it; which is another reason why languages such as ArchiMate and BPMN working together in an architecture repository support this.

I will speak at some point about ISO 42010 (I have a video blog planned), the standard for architecture design; how it fits in nicely with ArchiMate as a standard, and how it enables us to design architecture that supports our goals in a focused fashion. Such standards are essential if you are practicing architecture on a large scale. Each piece on a chess board has its purpose, and rules it must follow – each move must be part of a strategy.

It’s a matter of balance. We only want to do enough architecture to provide value; ISO 42010 provides the groundwork for this – when it describes views and view points – and the ArchiMate Language implements those concepts nicely. It takes skilled leadership with skilled architects in order to get this balance right in practice.

It’s essential we have an architecture strategy, and a good set of architecture practices to facilitate an agile way of working. You can’t be agile unless everyone knows what they are doing, how they are doing it and when they are doing it. Knowing why they are doing it can also be helpful. If you don’t have an architecture discipline then in fact architecture can become significantly less agile. To be agile we need competency and discipline; and we need to have an architecture practice, practice practice…. This doesn’t mean the solution is to do more architecture – more it means that we need to do the right architecture.

Summing it up…

Implementing without architecture design exposes all kinds of risks; it may seem that you implement projects faster, but then what you save in project development time, hits you when you get to an operational phase.

If architecture is not facilitating an agile way of working, then that architecture practice probably has a need to change, not to be abandoned. It’s important to have talented architects to lead us and define process that adapts to change. We need to consider process development and architecture with an agile mindset and should be considering how we can deliver continuous value over time as well as how we can do that efficiently. We need to build a layer of motivation architecture that hooks into our Implementation architecture.

To the guy that said “Agile or die, this is the only fact of today business environment”… I couldn’t agree with you more; but I would like to add trying to adapt to change without clear architecture, leaves you at the mercy of the skills and communication of the individuals, and the bigger an organisation you are, the more risky that becomes. So think of it this way:

Agile Architecture or die.

Planning Work With ArchiMate

Introducing a simple way to do basic architecture work planning using ArchiMate.

In order to keep control of architecture in a complex ever changing work its important to understand the workload. We often have complex projects interconnected, with shifting priorities; architects are asked for many things from stakeholders; to support both our architects and stakeholders I ask for a simple road-map with some supporting views. When a business stakeholder gives new priorities the architect can then easily take an intelligent conversation on what needs to be re-prioritized.

I Abstract away from real work and made up some examples here. So lets cover the Basics; Its far better to ask for basic views using only a subset of architecture elements than to expect fully blown models when you are trying to get a level of consistency and need to balance the levels of complexity with varying levels of competency you invariably face when dealing with a large number of architects.

The Work Package

The key element I want to talk about today is the work package in the implementation and migration layer of Archimate. Work is exactly as in English – its effort that is performed. We define the packages in architecture because it gives us many advantages – In modelling the packages we can accurately represent the effort our teams must take and the impact it has on our architecture over time. 

I tend to align work packages to the SAFe methodology even though we are not strictly using it at the moment – a work package is a unit of work that effectively can take 2 calendar weeks or more, and they should be modular; a package should provide value all by itself – rather than relying on anything else. This is important if we are to ensure we provide continuous value over time.

Work can be product related (implementing a new service within a product for example) or it may be related to a specific project or objective – for example we may have a concern around quality of a service which needs corrective actions for improvement, or we may have an initiative to reach a specific management goal.‚Äč

The Work Road Map

Something I ask all my domain architects to do is a work road map – anything that is going to take more than a week to complete or will tie up one or more resources should appear here.

I ask that the domain architect connects with both Product Manager & Service Manager in order to get a perspective of whats actually going on in terms of work within the specific products and services. 

Each block on the “Road map” (its a road map view in BiZZdesign’s Enterprise Studio) is a work package which has start and end dates. The arrows on this diagram are denoting dependency. We need to understand the dependencies between work packages, and in the example above “My Collaboration Program” is composed of several projects

Having all work modelled on the one road-map with the associated views allow us to ensure there is no duplication of work happening in the organisation and helps us understand our full workload – it should be regularly used with product managers to prioritise what happens next. Of course every work package on an architecture model can be navigated so we can understand all the places it exists.

We could add a number of other elements to the roadmap view – including plateau’s which would give us a stable state to connect architecture to – for now we are talking of the minimum basics.

Motivation View My Collaboration Program

Its important to note that this is a concern – not a risk – anyone can have a concern – it can be like a requirement, or we can express worries in the same way. Building a motivational view like this gives me something I can discuss with the different stakeholders; with a bit of practice you can create these in meetings, capturing concerns and assessments from the stakeholders. None of my motivation views have stakeholders expressed in them, because in our case the stakeholders are made apparent by the repository structure. I could include them in the motivation view.

There’s a school of thought that we should hide negative concerns, and I don’t agree with that – if we hide them, we can never fully address them, and also we may live with a wrong idea on something – for example, I could spend my career thinking that architecture workload for products is unclear and improperly scoped, when a conversation with the right person might simply inform me that I was wrong – there could be processes in place that I just haven’t been aware of, and for that reason, were never included in my architecture.

Motivational Views are there to explain why we do things. Above i show a simple motivation view – I have been advocating modelling something similar to above because of simplicity – the basic idea behind the view is to explain the “Why” behind the work packages we have – in an ideal world you can develop a full justification and more complex motivational model but for now –  The basic things we want to have answered:

  • Drivers – in the case above the driver / concern is a customer need. This driver reason behind why everything is happening for the work package. Normally I have one driver that’s motivating the whole view, at the top.
  • Assessments – These are the observations that are forming the rationale behind the work package. In a typical conversation with our stakeholders they will make many assessments on things that we could capture. and connect to our concern. When discussing with stakeholders they normally frame the problem (Driver) and then come up with a whole bunch of things to motivate that. These are effectively assessments.
  • Requirements –  Requirements are the glue that holds everything together in architecture and we could talk about them at length – For now in this simplified mechanism for drawing concerns we create requirements that would mitigate or provide a positive effect on our observations; for example if the observation is that “The media server crashes frequently”, then a good requirement might be: “Media server solution created & implemented to ensure a 99.999% up time”
  • Goals – The requirements together meet one or more goals. Its important that the goals address the needs of the driver.
  • Values – The goals have a positive influence on different values -we could define some standard values at our team level – so we can reuse them. If my boss says “We need to reduce maintenance costs” – we could easily automatically generate a view that shows all the goals that provide this value – and show the work packages with them. When we do that suddenly I can have an informed discussion with my boss – I can say – sure we can do that – but look at the road map – we need to de-prioritize some projects accordingly because of resource constraints – Its a much better discussion to have than answering “yes boss” and then trying to juggle a dozen projects you don’t have time for, get overly stressed and then fail to deliver anything.

I could have added positive or negative influences, I could have made our time restriction a constraint – many things could be done to improve the motivation view, but for the sake of simplicity I normally ask someone to do something basic like above.

Prioritizing The Requirements

Once I have the motivation views in place I normally prioritize the requirements – I am normally using MoSCoW rules (Must have, Should Have, Could Have, Won’t Have). This normally influences package definition – we may decide we address our requirements is several packages – for example, high priority tasks may need to be in a priority project and then you can define secondary projects that can be de-prioritized.

Implementation & Migration View

Once we understand the motivations behind our concerns we can take the requirements from our concerns and realize them within a work package like I have done below for the platform implementation project:

The above view further defines the work package.  The key components are:

  • The Work Package – which everything connects to.
  • The Roles – That are required with the work package – I find it handy to have the association relationships describe how much time is actually required from each resource.
  • The Requirements and Goals – these are from the motivational view – they tie the motivations to the work package.
  • Deliverables – these are things that the work package needs to deliver to be successful.
  • Other Architecture elements – A work package can realize any number of other architecture elements – for example we may create a work package to realize a specific service. 

Business Validation & Other Related Things

I will introduce a couple of basic mechanisms we can use to validate our work packages – none of which should take more than a few hours to create if you have a solidly defined idea of your business case and understand your audience. If you do not understand those things I would say the following practices are even more important. Its very important we do not start work unless we can clearly understand the scope of the work, or the values & benefits it provides.

Below I show a couple of typical requirements or principle that an organization might place upon its businesses; most organizations have some kind of principles we need to be aware of:

  • Products should be returning a revenue of 1MEUR – This doesn’t mean in a year necessarily – but the plan should be in place for when this will happen. 
  • For every EUR we invest we should have a return of 10EUR – Its a basic profitability rule of thumb.
  • We should try and get our product costs covered by pre-selling ideas to customers. Having a customer commit to buying a completed product fully justifies its cost.

User Stories

User stories are a basic form of requirement – they take the form : As <someone> I want to <do something> in order to <achieve some value>.

When you write a series of these with different stakeholders you gain a better understanding of who needs what and why. Take a look at the video:

TELOS

I have already mentioned TELOS in another blog – its an acronym used for feasibility checking. (Technical, Economic, Legal, Operational, Scheduling) Its another thing I could write a lot more about because it is so useful.

Business Model Canvas

When defining a work package for a service or product we may want to consider creating a business model canvas. A reasonable video introduction is below:

We can create a Business Model Canvas that connects directly into BiZZdesign’s Enterprise Studio – its a type of view that can be created in an Archimate model.

Summing It Up…

The mechanisms described here are not complex and do not take much time to implement. For myself, most work packages can be defined and modeled with associated motivation views inside of an hour – the modeling is not the hard part – the more difficult part is clearly deciding what your goals are, who you need, if your business case is strong, and requirements. modelling these individual elements forces an architect and their stakeholders to clearly think about every element.

We could talk in terms of risk here – if you cannot create a business canvas, for a service I could question the fundamental business case. If you cannot identify stakeholders a risk around the understanding of cost and basic feasibility could be raised.  With resources being limited and the need to deliver value being ever greater following the methods I describe above give you a good way to describe work and its implications and give a good foundation that can be used to continually manage a complex workload and ensure that the workload is prioritized in a way that you are getting the correct value at the correct time.

Architecture Languages, Standards And Frameworks

A discussion on the different architecture Languages, Standards and Frameworks I like to use in conjunction with each other when providing large scale IT & managed services..

My goal in these first posts is to introduce some of the basic ideas and concepts that we will build upon in later posts. I would love to present forward some things such as TOGAF ADM, and the ArchiMate full model, but those things are copyrighted so I can’t present them forward for now.

Modelling Languages

There are 3 industry standard mechanisms I normally use when modelling architecture; and although you may choose to use any other, the mechanisms below give a very good coverage of the different aspects of architecture, so when I talk about the role of architect within our company, I am normally having expectations on the languages I expect an architect to be able to communicate in.

An Example Implementation & Migration View in Archimate
  • ArchiMate – Is a modelling language that allows us to easily bring together different aspects of architecture (Strategic, Business, Application, Technology, Physical, Implementation & Migration, and Motivational). Its important we understand how the business is motivated, how it is realized, how our services are constructed and how these things connect together with both applications and the physical world below it. If we provide consistent architectures and have discipline most ArchiMate tools can provide invaluable business intelligence – I will blog on this further at a later date. Archimate perfectly complements TOGAF. Read more here.
  • BPMN – Archimate is good, but when it comes to understanding how a complex set of tasks are performed with multiple stakeholders BPMN shines – what would be done over several views in Archimate can be done as a single page with BPMN – its designed to model processes that look much more like traditional flow diagrams within swim lanes. I normally align these more in-depth BPMN processes with Archimate – For example in ArchiMate I model the process, with the different business events that align to the BPMN model. and normally assign the different roles and actors – but then the actual steps, happen within the BPMN model. Read more here.
  • UML – Is very good for low level data modelling & class modelling & has been around since the beginning of time. In EA I am tending not to use it too much, because at a high level I can represent data objects & their interactions with Archimate – But UML still has its uses with those who focus more on breaking information down into detail & those with a more application based focus. Read more here.
An Example of BPMN

Project & Architecture Governance

  • Scaled Agile Framework (SAFe) – I like this framework because its relatively simple to use and implement, and provides us a agile development methodology which supports us in a movement towards Dev-Ops, and the continuous delivery of value. Read more here.
  • The Open Group Architecture Framework (TOGAF). A lot of people have said to me that they feel this is a heavy framework that is monolithic and too documentation focused. It doesn’t have to be this way; we can adapt things to be fit for purpose. I think the framework nicely captures the things we need to consider in architecture. Read more here.

For me, a good working practice is actually a hybrid of these two mechanisms – because we need to flexible methodology that covers all the key areas but delivers continuous value.

ISO 42010

This is the international standard for architecture description – and its one of my favorites. When I first read it I was very excited, because it formally said a lot of things I had been standing on my soapbox about for years. It talks about how to describe architecture and covers core needs such as concerns management, and how these need to map onto an architecture solution that considers its stakeholders. Its under a 100 pages long and a recommended read for anyone who is serious about doing architecture.

The heart of ISO 42010

Adding Additional Value

This wouldn’t be complete without mentioning IT4IT and ITIL.

  • IT4IT – Provides a reference architecture for managing the business of IT; at its core is the IT Value Chain, and is very much focused on providing value to the business.. Read more here.
  • IT Infrastructure Library (ITIL) is a set of practices of IT service management – very well know, and very well supported. It can be used in conjunction with IT4IT. I do not know a good resource for free information on ITIL – there’s a lot of material out there though.

Summing It Up…

There are of course many standards we can apply at are equally as good as what I show above, but these are the ones that i found work well together and I like to have implemented together when i have a choice

ArchiMate is designed with ISO 42010 in mind, it’s by The Open Group, who also do TOGAF and IT4IT, so there’s a fair amount of alignment between these. SAFe and TOGAF require a bit of effort to establish good working practices. and IT4IT quite nicely facilitates ITIL which is very much an industry standard.

As always, feel free to comment my post.