Introduction to Arduino Workshop

Introduction to Arduino Workshop

On Saturday I attended one of Justin Mclean's introduction to Arduino workshops.  I learnt quite allot and had a wonderful time. Justin gave a short run down of the Arduino history and an overview of the main parts of the Arduino and where it was being used. I was surprised to learn it was being used in CubeSats now. Maybe this is a new opportunity for the postal service. Each home could get their own mini satellite up in space. The Arduino we got to use was the Arduino UNO. The link has all the specifications but it is a simple board with a set of digital and analogue inputs. You program it via a USB connection. Arduino has its own IDE and Justin supplies the software for both windows and Mac. I believe you can get it for linux, but we didnt have anyone using linux at this event. I didnt know i had to bring a computer with my so thankfully Mihail had a second laptop with him (Geek!). No issues starting up IDE, no issues connecting the device, I did have some issues finding the right COM port. Simple tip is to go into the Device Manager (was using windows) and check the Ports. Arduino will appear listed there. During the event i did find a few times that when i disconnected and reconnected the device the IDE lost access to the COM port. I simply saved my worked closed the IDE disconnected the device, then reconnected. Once I started the IDE again it was ok. The Arduino IDE is a C++ editor in essence. It was very simply to use but has the limitation of not having an intelligent Trace/Debugger. It does have stdout though so the good olde style of Serial.println("[Line 234]: broke here!"); still works. You can use TRACE but I havn't tried it yet. I have no electronics experience beyond putting together my own PC's, and a few of the JayCar kits (I had this one when I was a young boy and have been introducing my own kids to them). They have more interesting ones now - Fibre Optic Kit for instance may be more in touch with communications then the old radio was. Thankfully we were doing some simple things to provide a platform on which to build knowledge. The goals of the lessons where to understand the different in/out of the board, the way to program for it and how to load that program into the board. I like the enabling lessons over data dumps. I like to take bits and explore then come back for more so I enjoyed this one. We set about using different configurations of switches, sensors and lights to get different reaction. Generally to turn the lights on and off and then use programming to determine things like fade in and out, which colors and which lights. There are some very cool sensors out there for the device. I particularly like the idea of the clothing ones or eTextiles.  Maybe ill get a cheap suit from Lowes and make a touch screen for my arm sleeve so I don't need to wonder around with a laptop. Stuart laughed when mentioned the idea of a phone in my watch - 3 months later Apple announced IWatch.... Lets see if apple releases the ITailoredSuite any time soon!

Images from the day: Justin Mclean The Arduino Board and kit provide by Justin Some assembly required

We had a few breaks during the workshop were people got together and chatted. The group i was in was made up of IT professionals, enthusiasts and teachers. There was a nice Mexican resturant around the corner for lunch and as it was held right next to central very easy to get to. I recommend this event to anyone interested in exploring Arduino, Internet of Things or the Programmable Life .

You can catch Justin at his regular Internet of Things meet-up that he runs each month and he is looking to run more of the Arduino workshops and potentially some intermediate and advanced workshops. He will be speaking at TelSoc at the end of March and I am very much looking forward to his discussion on open source hardware and the Arduino system.

Fading In and Out.

MindMap from the event

ACS Talk - How to do Requirements Analysis in Complex Integrated Agile and Waterfall Development Environments

Sorry for this very late post, I was going through my backlog and found some missed articles.

There are many different ways of approaching agile in business and architecture, as a result I am always on the look out for different perspectives and views. This is why I went to the talk on "Business Requirements Analysis - How to do Requirements Analysis in Complex Integrated Agile and Waterfall Development Environments" back on the 23rd May 2013, hosted by the ACS Business Analysts Special Interest Group (BRASIG),  as I do work in a mixed project  environment where I may be on both agile and waterfall projects at the same time. The presenter for the evening was Dr Asif Q. Gill from the University of Technology Sydney (UTS).  Dr, Gill is an experienced enterprise architect and after many years in industry now focuses on both teaching and researching enterprise architecture. 

The main focus of the presentation was on how and when to utilise the multitude of processes out there to manage from inception to realisation business requirements. It was an interesting presentation and he does put forward a good case for 'adaptive' processes. Rather then offering a hack-it-up as you go approach he offers a framework which allows for the inclusion of different agile process elements where appropriate for a business. 

As he noted, agile is easy to explain but can be hard to adopt. This is the first time ive seen a maturity model for agile presented. Gill has the Agility Adoption and Improvement Model (AAIM) which represents the various stages which a business progresses through as it adopts agile. It is in the slide pack but here is the stages of maturity he offers. 

Figure 1 - The Gill Framework Agility Adoption and Improvement Model (AAIM)

I think the adoption model has value, to track the process. The feedback I have had from different companies doing agile all assume that once they have a process that is under the Agile Umbrella, then the goal is reached. I doubt this is the case. 

References

• Presentation by Dr Gill
• ACS Business Analysts Special Interest Group
• The Gill Framework 
• Agile Manifesto Principles

SOA Services in ArchiMate

Nick Laqua  posted an interested discussion question on the LinkedIn ArchiMate group. It was a long post so I wont repeat it here. But it was interesting and worth responding in detail to. The key areas of the post I am looking at are

• How to model a SOA service within the application layer
• Emphasis the view of a service as defined by the behaviour and functions over the interface

The issue of governance is a larger one which really deserves its own post as the levels of governance on services will vary within organisations based on the company structures, roles, size and many other factors.

I have been doing allot of this recently, experimenting with a number of different approaches. This approach I have found most beneficial for myself and in the communication of services to others. When modelling an application service I start with behaviours. It is essential to know what has been identified as viable for automation. Remembering that all programs are simply the automation of a process, we need to clearly identify the scope of the service. In Nick's post he mentioned a Customer Management service which offers 4 operations. Create, Retrieve, Update,  and Delete. First thing that springs to mind is an Entity Service. We need to consider how granular we need to go. If we are describing a service with the CRUD capabilities for an entity we can pretty much guarantee that there will be more reads then writes, and based on different interaction needs of systems we will need to be able to show what is reading and what is writing. This level of granularity will help implement the security policy for the service, identify performance hot spots, for instance or allow improved impact analysis during the governing phases.

Are we offering one service or 4 services? At this granular level we are offering 4 services.

Fig 1 - Services as Application Services

These are all different services that the application offers. If you say, 'Well the application does offer a SOAP services isn't that the service?' the answer is yes, but it is the Technology service.

Interfaces are access points, and there may be many access points. Lets consider that the above services have been implemented via multiple interfaces.

Fig 2- Interface assignments

This clearly shows how the services are available from the CRM application via multiple access points. The interfaces here are separated only by the technology they use. It may be more appropriate to show this capability as tied to the 2 technology services, HTTP and RMI.

Fig 3 - Infrastructure Usage view

This is a good way to show what functions are tied to what infrastructure. I have left off the Assignment relationships between the component and the functions for clarity.

I prefer to use the former view with the multiple interfaces as you begin to add both more interfaces for UI and consuming applications, you will want to know which interface are they interacting with, the RMI, HTTPS/SOAP or UI? You cant do it with this view (Infrastructure Usage).

So I maintain technology referencing interfaces at the application layer. It allows me to show dependencies and function utilisation.

Fig 4 - Detailed services view 

Personally this is my preferred model. Its not always good for communicating quickly the utilisation of services as there is allot of information there to take in. By aggregating the CRUD services under single service you can get a simpler view with derived relationships.

Fig 5 - Simplified services view 

In the model the more granular services become aggregated within the larger object, but now I have lost the information about which specific services each function is using from the service and the assumption is generally the entire service.

Fig 6  - Visualiser from Archi showing element relationships are maintained 

I find the detailed view very useful for identifying gaps and changes that may need to be made. It also aids with identifying high demand services and can lead to separation of granular services into their own space for performance such as caching layers etc. While the Infrastructure Usage view is the more accurate description for the language, IMO, it is less helpful, especially for integration scenarios rather then just SOA ones.

SOA Service Contract in ArchiMate

I have recently been doing allot of service solution modeling using ArchiMate as a result I have been exploring at how to model some of the common SOA concepts. One of the things I have needed to represent but not model in detail has been a service contract. So I thought I would give it a shot with a dummy inventory service.

The first thing I look at is the Service Capabilities. These I model as Requirement elements as then I can model the linkage back to business goals, stakeholders, drivers, principles etc. For this version I have created 3 prospective capabilities:

1. Search current inventory for stock
2. View Product detail
3. View Products commonly purchased with a given Product

So the proposal is to group these 3 capabilities together so that consuming systems only need the one interface.

Figure 1 - Service Contract

Here the Contract object in ArchiMate is used to represent a Service Contract. In the same way a Contract can be used to specify policies and rules for products here it is used to specify the capabilities that are to be realised by the service. The most useful aspect of using a tool that supports ArchiMate is that this view itself can be the contract. For instance in Archi it allows for the documentation of the View which can be named the Product Inventory Service Contract. Each element can detail the specific SLA, NFRs and basic functionality description. If you are working in an Agile environment you can quickly update the current state of the designs and requirements and reference capabilities to stories in Motivation views. This is something I will be going into in more detail in further posts.

We have also identified our basic information architectecture by showing the business objects the capabilities are associated with. We now have enough information to determine how agnostic our service is going to need to be.

The next step is to model the realisation relationships of the service contract. First I model the Contract as a descriptive data object, in this case a WSDL object. Then the behavioral elements that realise the capabilities.

Figure 2 - Service Contract and Capability realisation

The behavioral elements are assigned to an Interface which is the equivalent of a portType in WSDL 1.1 or Interface in WSDL 2.0. In this situation the capabilities and behaviors can be mapped to operations one for one but that may not always be the case. An alternative view can be presented with a single behaviour for the port type and the capabilities linked into it.

Figure 3 - Alternative Service Contract and Capability realisation

This view is simpler and though the operation names are lost, the capabilities are still mapped and the relationships are still clear. I have used both formats depending on my audience and how much detail I need to express. At times I have also shown behaviours within behaviours to show a Service->operation level relationship, but it begins to get very messy at that point and I don't recommend it. The operation level link to the interfaces can be useful especially when you want to show a WebSerivce implementing a behaviour and that same behaviour also exposed on an RMI interface.


A quick mapping of our data model to show the realisation from business objects to data objects results in:

Figure 4 - Data Model Realisation 

This is then aligned with the current service candidate:

Figure 5  - Service Candidate

We now have our service candidate. We can see how the service contract description is accessed by the interface and the data accessed by the different operations.

The next and final step to be shown here for the service contract is the technology layer. The goal now is to express the assets for the contract and the infrastructure interface and behaviour.

Figure 6 - Technology layer of the contract

The first thing to notice is the data has shifted from the right to the left hand side. Here I am showing the data defined by the XSD and the XSD imported into the WSDL file. The binding interface accesses the wsdl file. The behaviour element is not accessing any data objects as I have not modeled how the data is to be retrieved, this view is purely showing the contract for the service.

The major benefits I find with this is once you start to build up your library of capabilities you can very quickly trace through to find reusable services for new compositions and also navigate based on the Information Architecture of your business objects for applications and services.

ACS Foundation Talk "Jenny Wood, Director IT, Products & IT Enablement Telstra Coroperation -'Doing Less to Do More'."

On Thursday 23rd May the ACS Foundation hosted Jenny Wood, Director IT, Products & IT Enablement Telstra Corporation presenting 'Doing Less to Do More'. The talk was to provide students, local businesses and ACS members an opportunity to see how Telstra is currently changing and the potential value of working at Telstra. Of the students I talked to they were interested at looking at a combination of potential scholarships  and also some were looking at potential PhD opportunities as well. Unfortunately I did not have a chance to talk to many afterwards to get their thoughts.

I was there because I saw "Telstra, Lean, Agile" in the title of the upcoming events and so I grabbed the opportunity to have a listen to one of Telstra's leaders describe agile in the enterprise environment. I was very happy that I did as it lead me to meeting some very interesting people and some great information which is why it has been almost a week and I have yet to get through all the knowledge leads. I created a mind map of the talk:

Figure 1 - MindMap for ACS Talk by Jenny Woods

The foundation of Jenny's talk in my mind was how do you deliver more value with less waste and how do you change the workforce with new goals. This is the essence of Lean (Lean start ups  Lean Logistics, Lean Development, "Lean Etc"). With this goal in mind, Jenny outlined the key influencing methods, processes and tools that Telstra is adopting to achieve this goal.  She also highlighted some of the  many challenges that face Telstra:

• Rapid technology change
• Continued large take-up in M-devices (tables, smartphones etc)
• Changes in lifestyle
• Working in the "knowledge era"
• A new generation known as the Asset Light Generation
• Within Telstra there is the migration of old to new cultures
• Education of new methodologies
• Older style budgeting models
• Predictability in planning

In order to understand them a little better I have modeled them in ArchiMate showing the associated stakeholders and influencing drivers.

Figure 2 - Challenge drivers and stakeholders relationships

We can see from this model the challenges are not just faced by the company but by the customer as well. How do customers cope with the same drivers, and what are their needs as a result. Obviously a company needs to address these drivers and Jenny highlighted a number of ways that Telstra is approaching these:

• Deliver high value products
• Minimise scope at the start
• Decrease delivery times
• Minimise costs
• Achieve high flexibility
• Avoid providing solutions with no benefit
• Recognise if something is or isn't feasible
• Reduce work batch sizes for teams
• Minimise ramp up and ramp down of teams
• Minimise people working on multiple projects
• How to plan for more flexibility
• How to pick the right products that provide the best value
• Teams changes for focusing on value features

Here I have modeled their associations between goals to requirements as I interpret them from the talk. 

Figure 3 - Goals and realised requirements

There are a number of strategies and process frameworks that Jenny outlined for Telstra to realise this change. Jenny did describe that Telstra has had its success and failures in applying the frameworks but is constantly learning from their mistakes.

1. Cynefin for addressing predictability and decision making
2. Scaled Agile Framework (SAF) for a common agile methodology
3. Weighted shortest job first for prioritisation
4. Culture change

Figure 4 - Goals, requirements, and business processes

The  Cynefin Framework is quite interesting, it is a decision making process, where you establish within what zone you are, and then pick an appropriate strategy accordingly to move to a more desirable state. One aspect I was interested to see in it was the concept of probing for solutions when you are in the complex environment. The "Spike" in agile is the equivalent, if you don't know if something can be done, is feasible or what might be involved, you add a spike story to an iteration. This is in essence real-time R&D work, and I really like the fact that this probe-sense-respond mechanism not only answers the requirements portrayed but builds up knowledge along the way for both team members and companies.

The Scaled Agile Framework (SAF) is one of a number of scaled agile frameworks out there and I personally like the way it addresses some of the architecture questions, though I don't think it has all the answers. It does include the Weighted Smallest Job First principle and on that Jenny posed the question "Does the performance of an interface provide a better value to the customer using the account web page than improving the processing of the bill?" (paraphrased). Assuming there are 2 problems, A) the page load time of a customers bill is slow, B) the processing of the bill itself is cumbersome and could be improved. The customer only sees the poor functionality of problem A, but not of problem B. Problem A is a smaller task to fix, while the cumbersome process may be costing the business money, poor customer experience has direct impact on revenue.  Fixing the web site problem is also likely to be cheaper then overhauling the bill processing procedure. Its a faster win. Its a cheaper win. It doesn't mean problem B is never fixed, but it is not the priority so long as it continues to deliver the bill processed on time.

This ties back to Figure -2 where both the customer and Telstra are dealing with rapid changes and recognising what is the value drivers for both stakeholders. I am sure there where more in the talk I was nibbling on the lunch at the time. All of these processes do take alot of culture change. I have been through it, I have had friends who had had to deliver it, and I have had to deliver it at times and changing peoples attitudes to something can be difficult. Jenny described the current cultures in Telstra as:

Old Culture	New Culture
Control and command Functional silos Heavy governance with high cost Innovation is discouraged. Mistakes are hidden and not shared for learning Slow to react Budget success is finishing a project not delivering a value product	Adaptive and flexible Measure what it gets Entire team is responsible for delivery Focus is on value delivering over finishing work A culture of enablement Improve the way people work and live Teams pull work

To summarise one of Jenny's points, project management success, rather then being defined as "on time, within budget, and in scope" needs to be re-positioned along the lines of "delivering a high value product, or stopped with minimal waste". This sort of change requires changes in how people are evaluated, how projects are measured, when stop points are defined. I was talking with Nick about Business value a few weeks ago and he was mentioning an example for a project in another company where the BV was being tracked. At a mid point in the project the value droped below the story points delivered due to a revaluation by stakeholders of some of the stories. This is a clear indication that the project needs to stop and decide, whether to pivot into a new direction, or cease completely etc. Why waste money if you are not delivering value?

The questions asked were interesting, and you can see these and their answers on the mind map, they are on the green branch. On the whole I enjoyed the lunch and the talk and am looking forward to the next one.

References

• Leading the revolution By Gary Hamel
• Weighted Shortest Job First
• Scaled Agile Framework
• Cynefin
• Jenny Wood
• ACS Foundation
• ACS 

Publish Subscriber Pattern in ArchiMate

On the ArchiMate forum on LinkedIn, Stéphane Passignat posed the following question: 

"Publish Subscribe Pattern reprentation with data-object.

How would you represent data-object exchanges from an application component to another application component using ESB topic or any kind of pub sub pattern ?"

There are a number of aspects here:

1) ("using ESB topic") How do you model a Topic with associated data?
2) ("from an application component to another application component") How do you show the application using the topic?

3) ("any kind of pub sub pattern") How do you model generic Publisher and Subscriber patterns with associated data?

What is the Publisher Subscriber Pattern? 

This pattern is for an event to be broadcasted to multiple listeners. The same event may be broadcast by multiple originators. This is an Event-Driven Messaging pattern in SOA and a Publish-Subscribe Channel in Enterprise Intergration Patterns (EIP).

Enterprise Integration Patterns describes the problem as "How can the sender broadcast an event to all interested receivers?" The solution is a topic with one or more publishers and multiple subscribers.

Figure 1 - EIP Publish-Subscribe Pattern

Here it is very clear that a single message is delivered through a "channel" to multiple subscribers. I have created a very simple context for reference, however this time using the SOA template form Thomas Erl.

Figure 2 - Onboarding Scenario for context in the discussion

Here as part of an on boarding process an employee is added to a HR system. The service that configures the new employee broadcasts via a New Employee Event Service provided by ActiveMQ that the new employee exists. This message is picked up by the Create Account Service and an account is created into LDAP. I was also going to add the Training Enrollment Service as the second subscriber but one is enough to show the principle.

A Note on Syntax for ArchiMate

I am using the labeling syntax from Mastering Archimate Edition 1. It helps to identify what some of the objects are associated from other layers when not in a total view or using a tool like Archi which provides a visualization between layers while editing a particular view. It also helps in the menu to quickly grab the right object:

Figure 3 - Snapshot of Application elements from Archi

How do you model a Topic with associated data? 

The first one in ArchiMate can be done through a technology layer, describing how the infrastructure  provides a topic as an Infrastructure Service, an Infrastructure Interface and associated Artifacts.  Here in Figure 1, I have modeled an example of Fuse Message Broker(FMB) as the MOM layer for the ESB. FMB is an ActiveMQ implementation and for distinction I have named it as an ActiveMQ infrastructure.

Figure 4 - MOM Infrastructure with service, interface and artifact

Described is a virtual server with RedHat Linux, and ActiveMQ as a System Software. The underlying systems are all aggregated as ActiveMQ Node. The Node realises a the infrastructure service "New Employee Topic". The topic accesses a "New Employee Message" which is an artifact on the system. This could be stored as a file or in an RDBMs depending on the setup but for this I have not dived that deeply. The Node also presents and external Infrastructure Interface to the Topic. 

So how do you show the application using the topic?

Here I have taken the liberty of not modeling the infrastructure of FuseSourceESB. Instead I am modeling the services ('applications') deployed onto the ESB and how they access the infrastructure of ActiveMQ. I have done it through a Used-By relationship. There is a problem with this view. It does not show who is the publisher and who is the subscriber only which are using which. If there was only one publisher and multiple subscribers the Used-By relationship still would not identify the specific roles. In the Infrastructure with Usage view in ArchiMate there is no way of showing the flow.

Figure 5 - Infrastructure with Usage view of 2 service Components using the ActiveMQ New Employee Topic

Here we are at component level and we can see that the Employee data object is part of the New Employee Message data object via the composed of relationship.  In this view the Employee data object is accessed by the Configure New Employee but I have not shown the fact that the Create Account component would also access it once it had extracted it from the New Employee Message. I would but I want to highlight where it originates from this this case.

The infrastructure artifact is now shown as the realisation of that New Employee Message data object. It is accessed by the New Employee Topic infrastructure service to which the New Employee Topic Interface is assigned.  

How do you model generic Publisher and Subscriber patterns with associated data? 

The answer that I propose to the problem is Application Interaction using an Application Co-Operation View.

Figure 6 - Application Co-Operation view using an Application Interaction to describe a New Employee Event

Here we can see the Application Interaction showing the flow of the message from the one to application to another. The "Configure New Employee" function initiates the "Broadcast New Employee Event" function which flows to the "New Employee Event" interaction.

This Application Interaction shows a 3 way interaction pattern between the publisher the channel and the subscriber as per the Publish-Subscribe Channel pattern. You can easily add more subscribers to the flow though with ArchiMate you may find allot of overlap between lines so I would recommend a second view with all the subscribers and no data object once there is one view with a data object.

I hope this helps and feel free to suggest improvements and alternatives. 

ACS Forum: The Physics of Notation: Designing Diagramming Notations that Work review

I attended the ACS Forums monthly meeting at the Waterfront restaurant in The Rocks. The event had a great atmosphere and the people, food, and topics were excellent. I mind mapped the evening as I went through and then cleaned it up this evening, so it was a little more presentable.

The speaker was Dr Daniel Moody, Director of Ozemantics, and the topic was The Physics of Notation: Designing Diagramming Notations that Work. The talk focused on the problems of diagrams in the IT industry, and proposed a set of principals which could be used as the guide for improving the way visual languages are defined in order to improve communication between diverse groups. Dr Moody highlighted many of the current flaws with existing diagram development processes, including but not limited to,

• a 90% focus on content 10% on syntax, 
• a lack of employing visual designers 
• lack of consideration for the way the human visual system works
• intuitive and personal taste design over a measurable form 
• lack of design rationale for elements

The last one was perhaps the main focus, when an element is designed then there is little reasoning behind it. As he mentioned he was giving a similar presentation to a group and posed the question “why is the image for multiple events in BPMN a pentagon?” I must admit, I pondered it before he finished his story and assumed that each corner of the pentagon meant a direction for an event to occur thus multiple events. He then told us that the person who had designed that icon was in the room and told him “we had run out of symbols”. It makes you wonder.

The solution proposed was very interesting, in alignment with the idea of having a quality standard such as the ISO 9216 Product Quality quality model, he proposed a set of principals which could be used to give specific measures for how to create well designed visual languages. He went into detail on 3 of them, perceptual discriminability, semantic transparency, and semiotic clarity.

Perceptual discriminability is the ability to identify the differences between shapes. A circle compared to a square has a greater perceptual discriminability than a square against a rectangle. I found ArchiMate interesting, that a Business Service, Application Service and Infrastructure Service are identical in shape. I thought that colour was the key to their differences but as it was pointed out colour is not part of the specification.

 I missed noting down all the variables during the presentation, so my mind map is a tad lax there however I did find it interesting that the mind can use colour to differentiate 3 times faster than shape. It would be worth seeing a study if the same occurs for contrast, as I think colour blindness was highlighted a number of times as an issue with colour.

Semantic transparency is simply the visual equivalent of an onomatopoeia word, which is a word that sounds like the thing it is describing for example “boom”. So the visual representation of a boom should look like an explosion.

 I wonder how this would go with more abstract concepts. When you look at how a class is modelled in UML it can be modeled a number of ways depending on the view being used and the state of the object. For instance an active class, defined as “An active class is a class whose instances are active” has a notation defined as “An active class is shown as a rectangle with doubled vertical lines on the left and right sides.” An active class is something that is in action it is doing something, that same notation in flow charts means sub process.

Double lines on the road indicate do not cross, “=” is equals, and a quick search on google images turns up Double Line Stitch.  I like the double line stitch, can we suggest it to be the new image for an active class. It continues the rectangle motif through the use of negative space, and has the double lines but has many of them and aligned facing outwards indicating an active rather than passive state.

Semiotic clarity was the last principle dealt with in detail. This principal means that one symbol means one thing. Most of the languages have ambiguity in some of the shapes. BPMN has 2 shapes which mean can mean an OR gateway, UML has lines and arrows which will change meaning dependent on view, and ArchiMate has the same issue. I do suspect there are only so many ways of drawing a line so you would need to head down the road of line/shape combinations (arrow) inevitably and if there needs to be one for every meaning it may become a very heavy language depending on what it needs to explain. The goal here however is precision, being able to communicate precisely the intended meaning.

I have noted a few others in my mind map, and I will see what I can do about getting the full list.

Daniel also has a manifesto for notifications. I have them listed here though they may not be in the right order.

1. Explicit design rationale must be included
2. Explicit testing
3. Evidence based
4. At least equal effort and attention on syntax and meaning
5. Adhere to the principles

From my own experience I use diagrams all the time. On my desk are sheets of A3 paper for discussions, I carry around my “crayons” (white board markers) with at least 8 colours. I regularly use and abuse UML, flowcharts, BPMN, CRC, DFD, ERD’s and am now looking at how to add ArchiMate to my list of communication arsenal.  I found many of Daniel’s thoughts refreshing and insightful on the limitations of these visual languages and to look to ways to overcome them.