Modelling
These are some of the Opengroups Archimate 3.0 introductory basics videos we thought you might find useful.
Modelling
This blog on Services and Capabilities came out of thinking about a few related subjects:
1. How to use Archimate to model Capabilities as this is not directly supported in Archimate terminology.
2. On how Services relate to Capabilities. These seems to be a lot of discussion about this on the EA forums.
3. How all of the above should all be modeled in an Enterprise Architecture Model using any tool that supports Archimate.
4. How Architects who model hierarchical nested diagrams of one type (e.g. Application services) can see how this would still be possible.
So I thought the best way of explaining how I believe it should be modeled was to model one example situation in each domain for the following:
1. The Business domain – Business Service & capability – Route Planning example
2. The Application Domain – Application Service & capability – that supports Route Planning example
3. The ICT Domain – ICT Service & capability – the Database service that supports the above two.
So below is the Enterprise Service Model. It shows the typical structure of a whole Enterprise Services model. The services on this diagram (shown in green) give you one Business Service, one Application Service and one ICT Service; one service from each domain. On it I have only shown what has been modeled in the separate Models / diagrams in the sections below as well as any ‘used by’ services or ‘related’ showing service dependencies.
This model below is the Business Service and related Capability to support the ‘Route Planning’. Route planning comes from the notion of a travel agency establishing tailored itineraries for prospective customers. As you can see the Capability is shown as a ‘Business Interaction’ and is a collection of Roles, Actors, Processes, Artefacts, Locations and events, that all make up the Capability. The Business Service also depends in a large part on some Application Services.
The Route Planning Application Service is shown here in more detail. It shows the Application Services with it various Application Interfaces (some System/Machine and some Human). It then shows the Application Capability, again using an Application Interaction as the wrapper for all items that make up the capability, such as locations, Application Collaborations and Application Components. Each of these elements relies on ICT Services such as servers, desktops and other technology.
This is one Service of many that support the Application Service and its Capability elements. Again following the pattern of a Service having an Infrastructure interface and saying what should be done not how it should be done. The Capability expands on the detail of how it is realised. This is where I felt there should possibly be the same notion of an Infrastructure Interaction entity but Archimate does not seem to support that. This model also shows how the layers above it interact with the ICT Service, e.g. that the DB SQL Server (software) service relies on a DB Server (O/S & hardware) service.
While not wanting to re-invent the Archimate Meta-Model, I wanted to show the groups, and inter-relationship that this would build up in an EA Model of the organisation if we were using a tool to support this. The top part is the Portfolio and Programme office controlling the work-packages to do a transformation. They would need to understand the As-is and various Tranches of work per gap to get to a To-Be state. This they would primarily do of the higher level services, but could also go down to more detailed Capabilities to see the deltas between the various as-is and to-be plateaus.
It seems to me that many EA initiatives love to show the breakdown hierarchically of one Architecture building block type, e.g. Principles, or Organisational Business units, Services, etc. in isolation. I wanted to show by doing the above that all this information would be gathered in any case by working to build up these models. They would just be a by-product of gathering the above information.
The real value is to be derived from the interconnections and relationships in the meta-model of all of these elements below, including the entity instances themselves so that we always know what our inventory of them is so as not to forget things in doing analysis. The impact and dependency analysis is only obtained by connecting up the relationships between entities, provided it is done at a course grained enough level and we don’t try and model the whole world in great detail.
Modelling
The thought process was that since I am an Architect selling myself to other Architects, if I was to demonstrate some of the capabilities I am trying to sell the prospective clients out there, then why not use the very technique I would use in doing Enterprise Architecture to do the CV? An Archimate CV. After all the target market are the business and technical people in the business who require these very models. Also since the role is Architect, then an Architecture model describing what Architecture had been done before would be a good sample of my work.
Agreed, one has to get past the Agents and HR people in the process of reaching the end client representatives, some of whom would probably think I had sent in the incorrect document in instead of my CV, but I thought I would send them both versions of the CV in any case, the textual version and the modeled version to get around that small challenge.
I also thought it was unique and different too, because many of the Architects I know wouldn’t even be able to / nor interested in modeling in Archimate, so I saw it as a bit of a challenge to other Architects too.
This is a work in progress and will continually be re-factored over the next while.
Modelling
This follows on a previous blog on Why a CV in Archimate. This is Charles Edwards Archimate CV done mainly using the Archimate Notation with some pure text. For those not familiar with this you can find a Archimate V2.1 Key and Archimate V3 Key in the specification. This CV is organised chronologically from most recent to role going back in time.
Nationality: Dual British & South African Driving License: Full Mobile: +27 61 849 5792
Enterprise Architecture: http://www.AgileEA.com LinkedIn references: www.linkedin.com/in/charlesedwards
CV version: Last updated on 2017-04-03 (this blog will be updated from time to time to keep it current.)
Charles is a TOGAF Certified Enterprise Architect primarily with Architecture knowledge across all domains from Business to IT. TOGAF v8.1 in 2006, again certified v9.1 in 2013. Current interest in Business Architecture primarily. My background has been in founding and running a software development consultancy for half my career (first 14 years). The second half of my career has been spent contracting in Enterprise and IT Architecture and Software Development Processes (Process Engineering) mainly within the Financial, Payments, Telco, Utility and Government sectors. I have a strong Enterprise Architecture knowledge and provided leadership in process and methods being a keen advocate of the COBIT, TOGAF, Agile, Lean, SAFe methods. My passion and key strength is in Visual Modeling in multiple notations.
Modelling
Maybe it varies between countries and cultures, but it appears to me from my personal viewpoint, experience and in reading forums that many people, the vast majority, do not seem to find much if any business value in Enterprise Architecture visual models done in formal notations such as Archimate, BPMN, UML and the like, be that for Software Development projects or proper Enterprise Architecture. Besides the usual explanation of a picture paints a 1000 words and is therefore valuable, it is difficult to understand why this is the case? I have some ideas why this is the case but I’d be interested to hear other peoples views on this.
I am also specifically more interested in True “Enterprise” centric Enterprise Architecture, not the dumbed-down IT centric view of a sub-set of EA that is all pervasive at the moment. I am less concerned about the detailed software development models than the enterprise architecture level models, however there is an intersection between what data and applications are implemented in the organisation and the proejcts that implement them.
I am exploring this concept and have a few ideas as to why this change has happened and why I think it might still change back again somewhat, until we reach a happy medium somewhere in the middle.
Waterfall software development moved to a more agile and adaptive way of working.
The internet with eCommerce and Y2K came along and disrupted the way IT departments were beginning to work.
Finally, because when most people look at a visual model, all they see it as a stand-alone disconnected piece of information, not as a part of a larger whole, which if it came out of a joined up logically connected repository with a suitable meta-model behind it might not be so disconnected and stand-alone.
The logic of why Big upfront design got thrown out I do not question, mainly because by not delivering working software which is the primary goal of any delivery project, makes sense. However what we are now left with is years of “working” software (even the “working” aspects are sometimes questionable) without any reasonable documentation or architecture to explain what we have. Sure sometimes people write comments in the code, and other times fill out the wiki, but it never seems to be overly reliable or up to date, or is that just the case where I’ve worked?
But of more concern to me is the lack of backing business documentation about the original business and product architecture, which is even more of an issue when it comes to making changes to the original systems. So now when change comes, we do not have a baseline to work from, nor do we have too much of a systems architecture outside of the architects heads.
So when we have to make enhancements, there is very little context for people who are new on the team, or who did not live through the original project experience. Not only from documentation of what architecture exists currently that needs to be enhanced, but also the architecture of the explicit deltas of what we need to change are difficult to ascertain. This is where the business value of good models begin to make more sense. If we had some of this in place, then the changes would be quicker and easier to implement, and avoid the introduction of new changes that could break the original intention of the systems functionality.
The problem then is if we do not build these models during the development, when would be build these models? if we leave it too late, people have moved on and also it takes time to gather this valuable information and be accurate. Answer: We need some Cartographers to chart our systems, while the Scouts are out doing the development and transformation changes, just like in the old days.
Taking directly out of a AEA forum discussion Roderick Lim Banda shared this great analogy: “The one analogy I developed and continually use when engaging in AEA or EA as a whole is that of a navigator. In the days when the world was chartered by sea and reliant on navigators to both map and guide explorers, one could think of navigation in two distinct forms. There was a cartographer who would map and observe and guide Captains and there was the scout that would lead inland explorations. The latter would be part of the journey much like the “embedded journalists” of CNN that changed the nature of television news. But the trade off decisions made by the scout were critical and required that “quick of your feet” type of agility using knowledge and experience.
Today, many EA practitioners find they have to transition between Cartographer-Scout Navigation and this is why AEA matters if EA is to matter at all. As time passes, there is less to map but the journey and trade-offs are constant. And with scouts, all skills (human and technical) remain relevant – upon which survival against risk is dependent.”
So using the above analogy, there ought to be a separation of concerns and roles to optimise both delivery on its own delivery lifecycle and strategy on its own business-as-usual cycle as shown in the archimate diagram below. This means that we still get to gather the strategic information about the company, as well as not hold up development and delivery by causing extra modeling work to be done by the team. The Cartographer should do that part at any convenient point and do it regularly so that it is kept reasonably up to date.
I am only talking about information harvesting from Projects to the EA central repository here, not about the knowledge flowing in the other direction (from EA repository to Project), which is all about Governance and optimising Project level designs in the best interest and context of the organisation. That is a separate and relevant discussion not impacted by this concept, in fact it enhances this aspect because there is more collaboration and a deeper understanding of the facts between the parties.
Well, because it means that the information is gathered and captured into a central EA repository, consistently and therefore kept current and relevant for all elements in the enterprise portfolio.
Here we assume the use of a proper EA tool not a spreadsheet or visio diagram, unless it has an underlying central repository that is keep up-to-date. This means that any diagram is captured into or derived from the basis of a queryable set of related underlying information. This then gives the ability to do impact analysis, highlight traceability, keep records of architectural information (just like an ERP system does for the other parts of the business) – both in diagrammatic format as well as in textual database formats.
As I was finishing this blog, I got a tweet about the visual impact in marketing, which shows some interesting facts about how people perceive graphics over text. Why then is this not the case for models in companies? Or is its day yet to come?
http://blog.bufferapp.com/infographics-visual-content-marketing
Better still this blog should have been a Video Comic based presentation. Maybe I’ll find the time to do that instead. 🙂
http://en.wikipedia.org/wiki/List_of_cartographers
You must be logged in to post a comment.