Using TELOS For Validation & Feasibility Checking

TELOS is one of those handy acronyms we use for validation and checking we haven’t missed anything in architecture. This blog introduces TELOS.

I use TELOS quite a lot when reviewing architecture. One of the reasons why an architecture review with teammates often looks different is because when we ask questions on architecture what tends to happen is some of our lead architects run through TELOS in their heads – and focus in on areas where things need a little bit of attention.

We use it whenever we are looking at investment proposals, or we are presented with architectures or any kind of feasibility study.

Breaking it down.

TELOS is short for:

Some of the questions we ask can technically belong to several areas – such as a question “have you considered software licences for the servers?”. It doesn’t matter if the question is asked as a Technical question or a Economic one – the important thing is that questions are asked. Lets explore this this one part at a time.

Technical

This is things relating to technology. it can include things such as technical requirements, skills, capacity and other things relating to the fitness of the technical solution.

Some typical technical related questions:

  • Do we have the required software?
  • Do we have all the required hardware?
  • Are we reusing existing technology/competency wherever possible?
  • Do we have the skills we need to use the technology or will we need to train or get skills in?
  • Will we need external collaborations/have third party dependencies?
  • Will the solution defined meet initial performance expectations?
  • Will the solution defined meet mid term usage / functionality expectations?

Ive found in the past that its typical to not fully consider your skilling and training costs. I also think that capacity planning is also an area that often requires attention. Many times i have seen a positive problem occur, where a platform is implemented, costs and a return of investment are declared but the actual platform doesnt have the capacity to provide returns that are promised.

Its also important to think lifecycle of the solution and all its components. We need to have an understanding of how long technologies will stay relievent. For example if a software product we are using is several years old and a vendor is known for releasing new things every 2-3 years, will the solution realise its goals before we need to make further changes and incur more costs?

Economic

Relates to economy and includes such things as profitability, revenue tarkets and break even points.

Some typical questions might include:

  • Are all the costs defined?
  • Are all the revenue streams defined?
  • Have efforts been made to provide the most economic design?
  • Will there be an adequate return of investment?
  • How long will it take to show a profit?
  • How expensive is the solution? is it too expensive?
  • Is our pricing competitive?
  • What is the costs of any potential risks we see?

There are lots of mechanisms out there that can be used to help model and design a proper business case. As a minimum when looking at investment proposals I like to see a Business Model Canvas defined, because you can quite clearly see both costs and revenue streams. Of course not all architecture has a goal to provide financial value.

When looking at a promised return of investment we are looking for the reasons that justify things. Its not enough to say a product will return a million euros in the first year – we need to understand why – which raises further economy related questions

  • How big is your target audience?
  • What is the potential revenue for us of everything in the sales pipeline?
  • How often do we win these sales cases?

Legal

Describes things relating to legal.This can include ensuring we adhere to local law, EU Law, or any industry regulation, or contractual obligations.

Typical questions might include:

  • Are we complying to EU laws?
  • Have we ensured we are following all the ISO standards and met other commitments we have promised our customers?
  • Have we considered any industry specific legal requirements?

Some requirements are obvious – such as GDPR because it has such extreme implications and gets a lot of publicity. Other legal requirements are not so obvious. For example we may need to retain financial records for a fix length of time. Its important to ask the different stakeholder of an architecture about any potential legal requirements, so they are not missed.

Operational

Relates to things such process definitions, operational needs, lifecycle and change management

Some typical questions might include

  • Are all of the actors properly defined?
  • What kind of resources or teams in the organisation will be required?
  • Will we need to reorganize processes or teams?
  • Will we need new resources?
  • Have we made agreements with operations to implement our solution?
  • Will there be costs in training?
  • Do we have proper KPIs or automation in place?
  • Will new teams have to be established?
  • Will there be staff resistance to the change?

We talked about costs of training and skilling within Technology, but it doesn’t stop there. If we implement a new system or new processes / ways of working we need to ensure people are aware of them. There could also be formally required training, and needs for the building of a communication plan.

We also need to have mechanisms in place to monitor health of our operations so we can adjust our designs as we need to.

Proper architecture design really helps here. Resistance to change should also be planned for because sometimes one negative person can derail an entire project.

Scheduling

Things relating to resourcing such as timescales, road maps and resource availability planning.

Things relating to resourcing such as timescales, road maps and resource availability planning.

Some typical questions relating to this might be:

  • Given our current expertise are the timescales realistic?
  • Will the project be too resource intensive?
  • Will there be availability issues for key competencies?
  • Are there any timescale pressures that need to be met?
  • Will the solution be built in time to realize its benefits?

We need to be realistic with our timescales, and resource availability has major impacts on this. If resources are not available a plan should re revised because even with the best intentions you will fail. Time commitment for a percentage of time on a project should be time-boxed. if we have one day a week for a project we need to ensure all resources are available on the same day as part of that commitment, or projects will just drag on.

Key milestones or dates should be defined for things such as launches, and sometimes there are business impacts for being late that need to be understood. For example, when technologies are new the opportunity to sell them might be greater at the technology release than a year later.

A plan or road map should exist to ensure that the project / architecture is delivered at the cadence that is needed.

Summing It Up…

Its quite possible that going through this blog you come up with other questions that would need to be answered in a TELOS assessment, and the questions I have presented in this blog are not intended to be comprehensive so much as a starting point for people who want to start to use TELOS in their working practices.

The questions that I have asked in this blog do not necessarily get answered in a single document – although you might chose to have a TELOS section in a high level design. The questions can be answered in many places in our architecture. A road map view might exist to cover scheduling. A Business Model Canvas may cover most of the concerns we have in economy. Its possible we may cover everything in the requirements documentation or with use cases. Sometimes I have built TELOS into requirements templates, and sometimes I have built TELOS assessment templates. Sometimes its enough to just talk it through in conversation.

Knowing TELOS improves our ability to see potential risks or holes in architecture before they happen

.

Risk Analyzing BPMN Models

People often make risk assessments without a structured approach relying on intuition or experience. In this blog I show some methods I use to quickly identify risks in BPMN models when formal risk methodologies are not in use (such as SABSA).

As mentioned before in previous blogs, I normally do a process overview in Archimate, and then align it to BPMN because BPMN is easy to understand, and creating BPMN diagrams forces us to think about who is doing what, when.

Figure 1 – An example BPMN process

Design vs Run-time

At the highest level I normally thing of things in terms of design time vs run time risks. Design time risks are the ones that are happening due to the structure of the process and the decisions we have made in process build and run time risks happen when we execute the process. I will talk a little more about this in a while but its important we consider both aspects.

Running Through The Process With TELOS

TELOS (Technical, Economic, Legal, Operational, Scheduling) is an acronym we use for feasibility checking usually. If anyone is interested I can blog on this later. for now – the basics; we look at each of the tasks (the square blocks on the diagram) and ask these questions:

Technical

  • Do we have the software / hardware in place to perform this task? If a task requires the user to modify a Visio file, does he have Visio? Are we relying on a specific platform? For example if we need to read something from CRM, what happens if that goes down?  Are we relying on a system that isn’t in place yet or is due to be decommissioned?
  • Is it clear how to do this? Having the correct level of detail in the documentation is important. If we are creating or saving files for example, have we said exactly where to locate them?
  • Does we have the skills & competencies in place to execute this? Can the person who is expected to perform the task actually do it or do they need training on how? Are they sufficiently trained if something should go wrong?

Economic

  • Are we doing this the most economic way? For example, a contractor may be more expensive to perform a task than an internal resource.
  • What would be the economic ramifications of this step going wrong? Would it potentially be a breach in the Service Level Agreement (SLA)? Could it result in a major incident, or financial penalties?

Legal

  • Are we violating any known regulation? For example, Non-EU teams may not be allowed to work with personal information under GDPR. Legal requirements may exist for information retention if we are working with financial data so we may need to ensure it is kept as part of a process.

Operational

  • Have we used the proper roles? Its important that the right person is doing the job. For example, you would not design a process to have a Business Architect install a server. Even if its a particular Business architect has the capability to do it, that kind of work most likely belongs to a technical specialist; assigning the wrong resources can cause all kinds of issues..
  • Do we have the resources in place? In order to execute the process, have we thought through how often the process will be run, and If we have sufficient resourcing?

Scheduling

  • Will we be able to do all this when the process goes live? For example, will the training be in place? will the resources be in place?
  • Can the step be performed in good time? would the duration it takes to perform the step force a breach in SLA when you add it up with the related steps?

There are many further questions we could ask around a design using TELOS as our guidelines, but these are questions I will typically ask when risk analyzing the design of a process.

Run Time Risks

When analyzing run time issues I do this very simply. I look at all the relationships between each of  the elements and i ask my self the following questions:

  • What happens if the communication never happens? This normally breaks a process unless a contingency is put in place. A simple example; If we order something that is never delivered – is it a risk we need to handle? We can always handle risk as part of our normal escalations process but sometimes we want to put steps in place to be a bit more proactive. We could have a timed event in our process that after a week checks to see if the delivery arrived and if not escalates with the supplier, so that we get the required deliverable before it becomes a critical issue.
  • What happens if the communication is wrong? If we send an order for parts that is incorrect then that’s just as bad as communication not happening – if not worse.  Do we need to put in steps to check the communication before it happens, or are we willing to accept the risk?
  • What happens if the communication is delayed? an order delayed may lead to a breach in SLA – do we need something in place to avoid that?
  • What happens if a resource isn’t available? as well as individual resources not being available for each step consider what happens if resources aren’t available to perform a role at all… if nobody is assigned for example

What About Events?

The things that start and stop our processes, and the events we trigger and receive during a process should be handled with the same questions I listed for run time risk.

Lets Be SMART

Its another acronym – in the slide above it was about goal setting but it applies equally to process – we cover some of them already in TELOS but for each task in our process:

  • Specific – Is it vaguely defined or can anyone understand exactly what it is that you need to do exactly. For example “check that the architecture is good” can be interpreted in many different ways – “Check the architecture against the ISO 42010 Checklist” is a bit better defined. In the associated documentation you would also state where it is of course. if we are vague in definitions there is a risk we will be misunderstood, leading to communication overheads, and possibly the wrong things being done (an overhead in work).
  • Measurable – In defining processes we should also be defining metrics to ensure that processes are healthy. Those metrics should be clearly defined and measurable. If we have a process step to deliver something from point A to point B – we should probably have a metric to understand the amount of time that takes – which can act as a key performance indicator. if these indicators aren’t defined its most likely a design related risk.
  • Agreed Upon – Its OK to build a process with 10 different actors involved but each one must agree. Even if you are the manager of those resources, this step is still important because they may identify issues in process you do not see. If something is not agreed upon – there’s a risk that the execution may not happen according to design.
  • Realistic – You could define a process step such as “Get Owen to eat Broccoli”. That’s fine. Now try getting me to do it. If you define a step like that, there could be an associated risk!
  • Time-Based –  You should have a fairly good idea of how long each process step takes. If you cannot define this, its likely a risk.

Summing It Up…

What I have presented here becomes very easy once you have done it a few times, and without exception whenever I have personally applied these techniques I have identified unconsidered areas of risk.  I haven’t talked about mechanisms for determining impact and probability, but if you follow these guidelines I believe you will have better more mature risk analysis. Remember its not a bad thing to identify risks. When you identify risks, its OK if business wants to except them – and if they don’t you have improvement actions and quality goes up. When you show a risk list with many risks on it shows that you have done a good job in design, and identifying risks is the first step to solving them. These techniques arent as comprehensive as a full risk management methodology, but they are significantly better than just trying to guess what risks may occur. I hope you find this useful, if so, let me know.

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.