archimate Archives - Page 4 of 4 - Agile Enterprise Architecture

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.

Modelling

The perceived lack of business value of visual models

2014-07-232018-05-03
by Charles

Why is the apparent business value not found in visual modeling?

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.

My ideas as to why visual models have lost favour

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.

Visual modeling was seen as a blocker to making quick progress in development projects and therefore largely thrown out, with the exception of a few quick whiteboard models as a means to an end.
In the 1990’s – 1998’s when case tools were all the rage, people found value in visual models, for a period of time.
Then later too with Grady Booch & Rumbaugh, et al, in the early 2000’s with the Unified Process, RUP and UML (with its Use Cases, Class diagrams, etc.).
But since then as the more adaptive software development methods have come into play, some of the benefits it seems, like the baby have been thrown out with the bathwater. I understand why, but I have a potential solution to that.

The internet with eCommerce and Y2K came along and disrupted the way IT departments were beginning to work.

I know, I tried to introduce Enterprise Architecture concepts of Vision, mission, goals, objectives, strategy and capability models in a dot.com in 1999/2001 and failed miserably because nobody had time for such thinking, it was all Do or Die, Do Do Do, get to market, we are too immature to be doing all that big company stuff, Just do it!
Likewise Enterprise Architecture seemed to also be put on the back-burner between 1998 and 2007 for the same disruptive reasons of the internet coming of age.
This distracted everyone for a decade until we all got used to www….com’s and integrated this all into the traditional IT.

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.

People are so used to seeing Visio & PowerPoint diagrams, that there is no concept of and underlying database of information that joins all these concepts together. Many have never experienced some of the tooling that is possible, and if they are shown it, it simply does resonate very well.
Ironic because the CxO’s understand ERP, and realise we cannot run large organisations on Financial spreadsheets anymore, but are happy to run the IT department and more particularly Architecture on spreadsheets, PowerPoints or collections of files in a CMS like SharePoint.

How big upfront design concepts and modeling got stopped

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.

So how do we regain the business value?

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.

An analogy between visual models and the great maritime navigators of old using cartographers & scouts

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

Separation of Tactical and Strategic work during software development / EA development

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.

So how does all this enhance the business value of visual models?

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.

Finally some interesting information

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

References

http://en.wikipedia.org/wiki/List_of_cartographers

http://en.wikipedia.org/wiki/List_of_maritime_explorers

http://en.wikipedia.org/wiki/James_Cook

Modelling

Business Architecture Models

2014-07-252018-04-21
by Charles

Let’s all face the reality of it as it stands right now in 2014: As Enterprise Architects, and specifically those in the role of Business Architects, there is no real mature agreed set of Models and Operational Processes yet to follow to describe a fully mature Business Architecture in organisations. Sure there are bits and pieces all over the show that have evolved over time, but only now is it beginning to precipitate out into something more meaningful. Until then many of us are somewhat in the dark and all trying to pull together something meaningful which has some substance, works well and has some form of credibility with larger organisations.

We have input from the following sources (that I am aware of):

TOGAF
PEAF
Various specialized Business Architect companies own methods
BizBOK
etc.

So in the mean time I have been trying to derive my own Meta-Model of Models for Business Architecture. This is what I have come up with so far. This will be a work in progress and I’d be keen to have others give me feedback, point me to good places to find more and better information about Business Architecture in general and more specifically in Models and techniques used in order to build up an Enterprise wide Business Architecture.

This is what I started with today. I have used the Archimate notation with three types of element: 1. Meaning (clouds) to describe each model type as I see it. 2. Business Objects (blocks) to describe the Model. 3. The Association (line) to give the type of relationship between the Meanings and the Business Object Models.

Here are some simple instance examples of each type of Model (as I get to each one) click on it to see it:

Business Model Canvas
Business Motivational Model
Business Events Model
Business Value Network Model
Business Capability Model
Customer Journey Model
Business Organisation Structure Model, Business Actor Model (Archimate)
Services Model (traced from one capability requirement)
Services Contracts Model
Business Process Model (BPMN), Business Process Model (Archimate)
Location Model
Business Rules Model
Business Roles Model
Business Objects Model (UML Class), Business Object Model (Archimate)
Transformation Transition Roadmap Model
Applications Portfolio Model, Application Components Model (Archimate)
Business Products Model

And of course for each of these one or many model types one needs some sort of Operational Process Describing how to approach it:

Strategy to Execution process (this one needs to have some elements added into it such has define Business Model Canvas, etc.
many more….

I’ll evolve this blog and thinking over time to include Governance, Risk, Measurements of things like Enterprise Debt, etc.

Please feel free to put forward comments on this to grow it on one of the linked in forums – either on Business Architecture Community Forum.

Modelling

Modeling Services and Capabilities (2009 thinking)

2009-04-282018-05-03
by Charles

One view of the Enterprise Architecture is the Services View, where you can look at the whole enterprise from the Business capabilities, expressed as Services (or Capabilities – where conceptual and not yet implemented), through Logical Design Services, through Implemented Services, right down into the Physical implementation elements such as software infrastructure Services (like unix FTP components, Browsers, Middleware, etc.) and Hardware Services (Servers, Routers, Printers, etc.).

See example diagram below for a simple idea of these (using Archimate Notation):

I therefore believe that showing all the Services used in the Enterprise is possible at the right level of granularity. Services are more than just Web Services or the middle layer of this diagram “IS Application SOA implemented services”.

Modelling

Thinking through EA Modelling

2008-09-222018-05-08
by Charles

A chap from Troux technologies made some very interesting and enlightening points about Enterprise Architecture Modelling at a seminar in London recently. For me it was one of those Eureka moments, but also one of those things you’ve sort of known all the time but couldn’t put your finger on it and pin point exactly.

He was saying that historically software developers have seen the benefits in visually modelling the designs of software. We all know the old adage “A picture paints a 1000 words” that led to a proliferation in Modelling and Diagramming Applications (or are they called Tools? Why are we obsessed with calling Business software ‘Applications’ and IT software ‘Tools’? The subject of a separate blog no doubt.)

Visual modelling has grown organically from software development projects in IT outwards towards Enterprise Architecture in visually modelling and diagramming the various aspects of the organisation.Essentially a “model” captures entities and relationships and this information can be shown either visually in some notation or textually in lists of information based on some query. Intuitively though, the term “Model” implies “Visual Diagram” to most people; more than what it actually is “a well defined rigorous interconnected structure”. He also mentioned the other obvious meaning of Model such as those in London Fashion week, etc. Model can be a weather prediction system, Model can be a version of Car, or small plastic aeroplane stuck together using superglue.

The logic has been something along the lines of:

We need to capture information about the enterprise rigorously.
Rigorous information is made up of Things (Entities) and various types of relationships between the things (Associations).
We could do this in a relational database or in a visual modelling tool – ideally something that has both elements.
Database – We don’t have the time to design and write a whole database with associated visual modelling in order to do this properly.
Visual Modelling – We could make use of a Visual Modelling tool, which by nature allows us to diagram and model rigorously.
We also need to be able to store this information in a central or federated database.
We also need to be able to change the terms and relationships and icons in the underlying meta-model.
We also need to be able to report on this information. Oh great this modelling software allows that (well – sort of – I did a whole talk on this at the IBM Rational Conference in 2007)
We also want to publish all of this to the web for easy distribution.
Oh great this modelling software XYZ allows all that.
Or much worse. Let’s use Visio! (I have nothing against Visio actually it’s a damn fine product, just does not enforce rigour and store things once in a database)
Ok, so off we go…

Then some time later (months or years if we have managed to survive the politics of non-delivery that long):

Well we managed to build a meta-model which took us some time.
Well we’ve managed to get all this information into the Modelling tool, now lets query it.
Whoops not very easy to extract and report on information easily.
Whoops we have to buy an add-on to get it published to the web.
Whoops its not in real time, we have to manually generate output to the web.
It is a little difficult and time consuming to do impact analysis.
It is a little difficult and time consuming to do web publishing.
We’ve got too many visual models and not enough database manipulation ability.
Its not easy to navigate these visual models on the web, they don’t zoom and scoll easily, etc.

This is where Troux have made great strides technically I believe (and in some cases other vendors):

What we really need is a Web portal based tool that allows input and output from the web directly. Always up to date information.
What we really need is some sort of BI tool at the reporting and output end to optimise the queryability.
So lets look for a tool that not only has a visual capture and DB capture mechanism but also one with a Data warehouse and BI output.

But even Troux have issues, because guess what? BI tools are weak in the Visual output of information.

BI and reporting tools tend to be more Textual than Visual.
So now Troux have generated reports using the BI tool, but make up for certain Visual Querying where BI tools fall short until the BI tools catch up. Good on them.

So what is the upshot of all this? He was saying, if we think about what we mean by Model, then we will realise its more than just a set of Visual diagrams. It’s more about a well defined and interconnected System of Virtual Information about the Enterprise from which you can derive IT wide Decision Support. Actually I prefer to think of it as the missing piece in the overall Knowledge management of the whole Enterprise, IT just happens to be one of the users of this information, and it has stemmed out of IT by necessity.To me it’s about:

Being able to split the concepts of Visual Models and Database textual information up into Input, Processing, Interfacing and Output.
Input – How do we capture the Entities and their Relationships? Ideally though using both Textual or Visual Modelling input.
Processing
- Views and Viewpoints – The ability to take one of many dimensions, e.g a Cost view and see all models (diagram and text) though this filter. Or a Strategy View, or a Policies View, or one of potentially hundreds of definable Views, etc.
- Motion – Animation on models, to turn 3D into 4D over time. e.g. Visual As-Is to one or many To-Be alternatives.
- Better Config Management. e.g only Publish everything that conforms to a baseline as at the end of last week, even though we are working on new changes to the central model which we will release next week. So this means version control, Version-of-collections of versions etc.
- Non-rigour Capability. Ability to contain, store and preserve not only Rigour and Predictable process type information, but also the less mechanistic and highly valuable un-predicatable, changing and loosely connected information in something along the lines of a wiki. (Subject of a separate blog later.)
Interfacing – Control in both directions (inward and outward) of feeds into and out of the model. Into using fancy ETL controls to ensure the Model integrity. Outward in terms of exposing the Data and Visual Query Services on an ESB for the rest of the enterprise to access where necessary in their applications.
Output – How do we report on extract information from our Entities and their Relationships? Ideally though Database and Visual Modelling output. Some things are better understood in a textual form, and others in a Visual form. Ideally both mixed.