Charles, Author at Agile Enterprise Architecture

Example Services and Capabilities with Meta-Model

2014-11-092018-05-08
by Charles

Introduction

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.

Enterprise Service Model

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.

Route Planning – Business Service & Capability Example

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.

Route Planning – Application Service & Capability Example

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.

Database Server (for Route Planning DB) service – ICT Service & Capability Example

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.

Meta-Model that brings it all together

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.

Other Model Views

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

Why a CV in Archmate?

2014-07-142018-05-08
by Charles

Background

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.

Challenge to other Enterprise Architects

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.

CV

This is a work in progress and will continually be re-factored over the next while.

The CV can be seen here.

Modelling

Charles Edwards Archimate CV

2014-07-102018-05-08
by Charles

Introduction

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.

Personal Details

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.)

Summary

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.

Second Half of my Career (1998 – current) – contracting / consulting

Enterprise Architect @ Sanlam – Cape Town, SA
Enterprise Architect @ Old Mutual – Cape Town, SA
Business Architect @ Plymouth City Council – Plymouth, UK
Business Architect, Enterprise Architect & Solution Architect @ Fundamo.com (Visa) – Cape Town, SA
Enterprise Architect, Data Architect & Solution Architect @ Fin Services Authority (FSA) – London, UK
Enterprise Architect @ Catlin Underwriting in London, UK
Enterprise Architect @ Network Rail in London, UK
Enterprise Architect @ LCH.Clearnet in London, UK
Process Architect @ MTN (a Mobile Telco) in Johannesburg – South Africa
RUP Project Manager @ LCH.Clearnet in London, UK
Process Architect / Mentor @ BACS and Lloyds TSB in London, UK
Process Architect @ HSBC in London, UK
Development Manager & RUP Process Engineer roles @ Earthport.com in London, UK
Delphi OO Developer @ Nationwide

First Half of my Career (1984 – 1998) – ran my own software development company

CEO & founder of a Software Development & Consultancy company for 14.5 years in Durban South Africa
Clients included: Mondi, Sappi Forestry, SA Sugar Assoc, Reutech (Defence), Lipton, SA Nylon Spinners, Telemecanique, Rudolph Chemicals, Umgeni Water and Robertsons.

Extra

Charles has done multiple Enterprise Architecture Tools Evaluation and procurement exercises.
He has spoken at 6 international conferences in the last five years;
Charles also built and runs www.agileea.com

Hard Skills

TOGAF 9.1 and 8.1, Zachman, BIZBoK, IEEE 1471, MODAF, ITIL, COBIT, CMMI, SPEM, BMM, ETOM, PEAF, POET, APQC, IBM IAA/IPS, OpenStack, BCBS239
Techniques: Gap Analysis, Road-mapping, Portfolio planning, Business Model Canvas, Capability Modeling, SWOT, Strategy Value mapping, Decision Rule modeling, Target Operating Models, Blueprints, etc.
Modelling Notations: Archimate, UML, BPMN, ER Data Modelling, Cisco network, BMC, Cust Journey.
SOA & Web (HTTP, XML, UDDI, WSDL, WS*), IBM WebSphere, Oracle Fusion, JBoss Fuse, WSO2, JEE, ESB, MQ, MDM, IAM, ETL, REST, API, JSON
Data: BI, DWH, SQL, RDBMS Oracle+SQLServer+MySql, NoSQL Hadoop, Hive, Pig, scoop, oozie, Solr, DocumentDB, redis, PowerBI, Azure SQL DW, SSIS, SSRS
Security: XSS, SQL Injection, pen testing, SAML, PCI-DSS, ISO27000, OSA, CISA, SSO, SABSA.
Scaled Agile Framework (SAFe), DAD, Rational Unified Process (RUP), PRINCE 2, SCRUM, XP, SDLC.
EA Tools: Orbus i-Server, Inspired.org’s EVA, Casewise, Troux, ProVision EA, Aris, System Architect, IBM RSA & Rhapsody, Mood Bus Arch, ERWin, Sparx Enterprise Architect, Power Designer, Dragon1.com
DevOps tools: Eclipse, Jira, Subversion, Puppet, Jenkins, GIT, Artifactory, ClearCase, ClearQuest, ReqPro.
Other tools: SharePoint, Joomla, EPF, Zoho Creator & Zoho CRM, Confluence, Talend MDM
Cloud: AWS Cloud, Azure, Openstack, VMWare ESX
Communicate with confidence at all levels. / Excellent inter-personal, written, leadership and presentation skills / Collaborative – Excellent team, workshop and JAD facilitation skills.

Soft Skills

Articulate – able to communicate with confidence at all levels. / Excellent inter-personal, written, leadership and presentation skills / Collaborative – Excellent team, workshop and JAD facilitation skills.

2017-01-to-2017-02 – Sanlam – Enterprise Architect Role

2015-05-to-2016-12 – Old Mutual – Enterprise Architect Role

2014-10-to-2015-02 – Plymouth City Council – Business Architect Role

2013-04-to-2014-06 – Visa – Business Architect Role

2012-10-to-2013-03 – Visa – Enterprise Architect Role

2011-06-to-2012-09 – Visa – Solution Architect Role

2011-01 to 2017-02 – Africa4Adventure.com – CEO

2009-09-to-2010-12 – FSA – Solution Architect Role

2008-06-to-2008-12 – FSA – Solution Architect Role

2008-01-to-2009-08 – FSA – Enterprise Architect & Data Architect Role

2007-11-to-2008-01 – Catlin underwriting – Enterprise Architect Role

2007-09-to-2007-11 – Network Rail – Enterprise Architect Role

2006-06-to-2007-07 – LCH.Clearnet – Enterprise Architect Role

2005-05-to-2006-04 – MTN – RUP Process Engineer Role

2003-12-to-2004-10 – LCH.Clearnet – RUP Project Manager Role

Previous roles include:

Process & Solution Architect / Mentor @ BACS, Aug 2003 – Sep 2003 (2 months)
Process & Solution Architect @ Lloyds TSB (Concise), Aug 2002 – Jul 2003 (11 months)
Process Engineer Consultant @ BACS (Concise), Aug 2002 – Jul 2003 (11 months)
Solution Architect Mentor @ HSBC Investment Banking, Mar 2001 – Nov 2001 (9 months)
Development Manager & Process Mentor @ Earthport.com PLC, Aug 1999 – Feb 2001 (18 months)
OO Delphi / VB Developer (COM Specialist) @ Nationwide Trust, 1998 – 1999 (1 year)
Technology Enterprise Architect @ Umgeni Water (South Africa), 1993 – 1996 (3 years)
CEO and founder of a Software development house Time 2 Talk CC (South Africa), 1985 – 1998 (14 yrs)

Professional Qualifications

Processing Big Data with Hadoop in Azure HDInsight (Certificate 2017)
Developing NoSQL Solutions in Azure (Certificate 2017)
Interpreting and Communicating Data Insights in Business (Certificate 2017)
Delivering a Data Warehouse in the Cloud (Certificate 2017)
IBM Insurance Application Architecture (IAA)/Insurance Process & Services, 4 days in April 2016
Orbus i-Server – Admin and Modeller course – 4 days in 2015
Business Architect – Techniques – 4 days course (from Inspired.org) in 2014
TOGAF 9.1 Certified Architect, Nov 2013
Mendix Apprentice Certified 2013.
TOGAF 8.1 Certified Architect, summer 2006
RUP, UML, Use Cases, ReqPro, Rose, ClearQuest & ClearCase and Rational Tools Certified over 2000 – 2003
BSc in Computer Science (information systems), University of Natal Durban 1984
Attended numerous courses over the years on: unix, SQL, OO, UML, Delphi, Java, XML, SOA, Information Engineering, Requirements, Information Architecture, etc.

AgileEA Process

EA Conference 2009 – Agile EA: A Step change…

2009-06-132018-05-08
by Charles

Abstract – Agile Enterprise Architecture Step change required

This was the presentation given at the RealIRM EAC 2009 in London.

The title was Agile Enterprise Architecture: A Step change is required.

Download

Get the .PPT here (4.2 Mb)

Enterprise Architecture

Who should own Enterprise Architecture?

2009-03-282018-05-08
by Charles

The clue about Enterprise Architecture ownership is in the title. One of the issues I see as an EA practitioner all the time is the fact that Enterprise Architecture typically falls within the IS/IT Department remit within many enterprise organizational structures and not where I believe it ought to be positioned. EA should be part of the Strategy Department under the CEO and therefore divorced from either the Supply or Demand side of the Enterprise, thereby governing from a neutral position and informing the executives of the enterprise. EA positioned within IS/IT it’s like having two opposing Lawyers in a court room where one of them is also acting as the Judge; the verdict is always only going to go one way.

Why is EA in IS/IT mostly? The reasons for the evolution of EA being owned within the IS/IT department are quite understandable. The practice of Engineering and Architecting systems and systems-of-systems stems primarily from the Technical domain rather than the Business domain, out of a need to build and supply rigorous software and hardware systems.

The business domain have used simpler diagrams to show concepts, to collaborate on ideas and thoughts, but till more recently the business have never had to be very rigorous other than in the financial sense. More recently the business domain is dealing with more formal business processes diagrams that generate working software, so the rigour is beginning, and so too is the understanding.

Whereas the Technical domain has relied on a far more rigorous diagramming notation to formally build and help implement systems. Architecture does not stop at diagrams; Requirements have to be formally managed and traced, Configurations of systems have to be managed, Change controls have to be managed, Testing, Hardware connectivity for LANs and WANs have to be formally managed, etc.

The common currency between the Supply and Demand has been money, time and power. All discussions have come down to the first two with the third making the final call. These are only the tip of the iceberg. Unfortunately none of these involve complexity and the buildup of “Enterprise Technical Debt“.

Hence the practice of building up Architectures and being able to Govern and manage complex systems has mostly evolved from the Engineering side. The Technologists have understood why this is important to them. They have built mechanisms to cope with complexity such as Abstractions, Visual Modelling, Configuration and Change Control management systems, Reusability, Services, Test, Build and Deployment automation, etc.

So with this in mind, if you look at an Enterprise from a Supply and Demand point of view, in general Business drive the Demand and Technology Supplies the solutions. On the demand side you would expect to see motivation, direction setting and strategy, which ties into the time and money available.

On the Supply side you’d expect to see a reply to that Demand given certain principles and constraints such as ensuring re-use, avoiding duplication of resources in terms of Servers, Data, Functionality, etc.

Put all this into a negotiation between Demand and Supply and somehow out of all of it, certain compromises get made on both sides.

Generally Business give up functionality and Technology gives up coherent Architecture. In order to control and regulate these conflicts of interest IS / IT departments have implemented Governance processes, at various levels, Programme and Project, Architecture, Service management, etc.

The challenge is that as the ever technically savvy Business submit Demands on the Technology Supply side, how can IS/IT possibly govern these compromises if they are not empowered to straddle both sides of the debate? An IS/IT based Architecture governance is not in a position to rule against the Business, particularly if the Business hold the purse strings and are the Demand “Customer”.

Consequently IS/IT want to make themselves look good by trying to deliver on time and within budget, and start compromising on their own principles by ignoring the Architecture governance outcomes, or offering endless Waivers and Dispensations. Many Supply side Risks and Issues are never feedback into the Business on the demand side, and even if they are fed back, many times it’s too late or the business cannot interpret the meaning. Ultimately the Enterprise is compromised over time. The Enterprise Technical Debt builds up and builds up until all ability to make any change at all becomes impossible. Any change costs too much or takes too long. All Agility is lost.

Instead if a small Enterprise Architecture team of practitioners made up of Business Architect(s), Information Systems Architect(s) and technology Architect(s) are put into a “Strategy” team under the CEO, who liaise closely with the IT Solution Architecture team, and the Business subject experts then, the equilibrium should be restored. The IT Solution Architects should still remain under the CIO and not directly report to the “Strategy” (or some more meaningfully named) EA team. This assumes a lot of collaboration, communication and engagement between all parties. The “Strategy” EA team should have the necessary technical and business background to feedback the overall Risks in the business and thereby avoid the inevitable Enterprise Technical Debt build up over time.