Skip to content
Agile Enterprise Architecture
  • Home
  • Services
    • Remote Services
      • Looking for EA modelling?
      • Why Arch-as-a-Service?
      • Modelling-as-a-Service
      • Assess Arch Maturity Free
      • Arch Modelling Notations
        • Archimate model types
        • Quadrant model types
        • Canvas model types
        • UML model types
        • BPMN Model types
        • DMN Model types
        • ERD Model types
        • Structured Info types
        • Cisco model types
      • Arch Modelling tools
    • Consultancy Services
      • Digital Integration Services
      • Business Architecture
      • Health check services
        • Arch Risk Assessment
        • Arch Governance checkup
        • Arch Models health check
        • Arch Content health check
    • Cloud Hosting services
      • EA SaaS – Orbus iServer
      • EA SaaS – EVA Netmodeler
      • EA SaaS – Dragon1
      • Meta-Model Structuring
  • Blogs
  • About
    • Our AgileEA Business Model
    • Our AgileEA Principles
      • Open & Transparent
      • Value for money
      • Keep it simple
      • Love what we do
      • Efficient & effective
    • Location
DataFabric Information & Data

Data Fabric Framework – Archimate 3.0 model

  • 2018-05-102018-05-11
  • by Charles

Introduction

I happened upon a really great Data Fabric model done by Alan McSweeney and thought it would be useful to have this Data Fabric Framework in modelled Archimate 3.0.

Original Data Fabric model

Alan kindly sent me the original to look at in more detail and be able to cut and paste quicker. He gave me permission to convert it and even collaborate on making it it better in the process.

Data Fabric Diagram
Alan McSweeney’s Data Fabric Diagram

Archimate Data Fabric (high level) model

This is a high level view of the various components necessary for a holistic Data Fabric framework. We have a more detailed model for each of these component packages in each of the sections below.

Data Fabric Architecture (High level)

Archimate Data Fabric (more detailed) model

This model is the A0 sized page that contains all the information needed. Each of the packages in this model, are modelled separately in the sections below with the same names as the fabric component name.

Data Fabric Architecture (More Detail)

Fabric Component 01 – External Interacting Parties model

These are the range of external parties that supply data to and access data from the enterprise.

Fabric Component 01 - External Interacting Parties

Fabric Component 02 – External Party Interaction Zones, Applications, Channels and Facilities model

These are the set of applications and data interface and exchange points provided specifically to External Interacting Parties to allow them supply data to and access data from the enterprise.  These can be hosted internally or externally or a mix of both.

Fabric Component 02 - External Party Interaction Zones, Applications, Channels and Facilities

Fabric Component 03 – External Party Interaction Zones Data Stores model

These are applications and sets of data created by the enterprise to be externally facing where external parties can access information and interact with the enterprise.

Fabric Component 03 - External Party Interaction Zones Data Stores

Fabric Component 04 – External Third Party Applications model

These are third-party applications (such as social media platforms) that contain information about the enterprise or that are used by the enterprise to present information to or interact with
External Interacting Parties or where the enterprise is referred to, affecting the perception or brand of the enterprise.

Fabric Component 04 - External Third Party Applications

Fabric Component 05 – External Data Sensors model

Sources of remote data measurements.

Fabric Component 05 - External Data Sensors

 

Fabric Component 06 – External Data Devices model

These are devices connected with services offered by the enterprise (such as ATMs and Kiosks).

Fabric Component 06 - External Data Devices

Fabric Component 07 – Data Intake Gateway model

This is the set of facilities for handling data supplied to the enterprise including validation and transformation including a possible integration or service bus. This can be hosted internally or externally or a mix of both.

Fabric Component 08 - Line of Business Applications

Fabric Component 08 – Line of Business Applications model

This represents the set of line of business applications deployed on enterprise owned and managed infrastructure used by business functions to operate their business processes.

Fabric Component 08 - Line of Business Applications

Fabric Component 09 – Line of Business Applications hosted outside the organisation model

This represents the set of line of business applications deployed on external infrastructure used by business functions to operate their business processes This includes cloud facilities such as external data storage and XaaS facilities and an integration service to connect external data to internal data

Fabric Component 08 - Line of Business Applications

Fabric Component 10 – Desktop Applications model

These are applications used by individual users to view and author documents.

Fabric Component 10 - Desktop Applications

Fabric Component 11 – Data Storage Platforms model

Operational Data Stores – These are the various operational data stores used by the Line of Business Applications. Unstructured Data Stores – This provides structured access to documents and information including externally hosted applications providing these facilities.

Fabric Component 11 - Data Storage Platforms

Fabric Component 12 – External Application Operational Data Stores model

These are the various operational data stores used by the Line of Business Applications used by Line of Business Applications Hosted Outside the Organisation.

Fabric Component 13 – Document Centric Applications model

  • Doc Management Systems – These are systems used to manage transactional and ad-hoc structured and unstructured documents in a formal and controlled manner, including the metadata assigned to documents.
  • Doc Sharing & Collaboration – These are tools used within the enterprise to share and collaborate on the authoring of documents.
  • Document and Information Portal – This provides structured access to documents and information including externally hosted applications providing these facilities.

Fabric Component 13 - Document Centric Applications

Fabric Component 14 – Cloud Extension to Data Mastering, Reporting and Analysis Facilities model

These are facilities to create and manage master data and data extracted from operational data to create a data warehouse and data extracts for reporting and analysis. This includes an extract, transformation and load facility These can be hosted internally or externally or a mix of both.

Fabric Component 14 - Cloud Extension to Data Mastering, Reporting and Analysis Facilities

Fabric Component 15 – Data Reporting and Analysis Facilities model

This represents the set of facilities to extract operational data from business applications, create, store and manage reference and master data, create and store enduring data and analyse the data including reporting, visualisation, mining and modelling. These can be hosted internally or externally or a mix of both.

Fabric Component 15 - Data Reporting and Analysis Facilities

Fabric Component 16 – Data Mastering model

These are facilities to create and manage master data and data extracted from operational data to create a data warehouse and data extracts for reporting and analysis. This includes an extract, transformation and load facility These can be hosted internally or externally or a mix of both.

Fabric Component 16 - Data Mastering

 

Conclusion

You are free to download the printable versions in .PDF form. We may have more discussion and refine these models. Of course we also welcome comments and recommendations for improving these models as well.

Downloads

Data Fabric Architecture (High Level) PDF. (A3 or A2 size)

Data Fabric Architecture (More Detailed Level) PDF. (A1 or A0 size)

 

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

Cartographer Vs Scout Roles

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

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

Modelling Services And Capabilities

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

Posts navigation

1 2

Categories

Tags

Agile AgileEA-Process archimate architecture practice business-arch Business Uses cases Capabilities cloud culture Data Architecture Enterprise Architecture health checks IoT maturity openstack Requirements Services strategy System Use Cases techical debt train44ir Use Cases Values visual models

Recent Posts

  • Announcing Our Train44Ir.org charity 2020-04-24
  • Data Fabric Framework – Archimate 3.0 model 2018-05-10
  • OpenStack Cloud Metering in Archimate – Part 10 2017-04-28
  • OpenStack Cloud Orchestration in Archimate – Part 9 2017-04-28
  • OpenStack Cloud Identity in Archimate – Part 8 2017-04-28
  • OpenStack Cloud Object Storage in Archimate – Part 7 2017-04-28
  • OpenStack Cloud Images in Archimate – Part 6 2017-04-28
  • OpenStack Cloud Block Storage in Archimate – Part 5 2017-04-27
  • OpenStack Cloud Compute in Archimate – Part 4 2017-04-27
  • OpenStack Cloud Networking in Archimate – Part 3 2017-04-27
  • OpenStack Cloud Dashboard in Archimate – Part 2 2017-04-27
  • OpenStack Cloud in Archimate – Part 1 2017-04-27
  • Hosting and Cloud Software Delivery modelled in Archimate 2017-04-19
  • Why do Architecture Maturity Assessments regularly? 2017-03-22
  • Archimate 3.0 introductory basics videos 2017-02-28
  • Example Services and Capabilities with Meta-Model 2014-11-09
  • Why a CV in Archmate? 2014-07-14
  • Charles Edwards Archimate CV 2014-07-10
  • EA Conference 2009 – Agile EA: A Step change is required 2009-06-13
  • Who should own Enterprise Architecture? 2009-03-28

Previous Posts

Our Twitter Feed

My Tweets

Recent Comments

    Translate site

    Tag Cloud

    Agile AgileEA-Process archimate architecture practice business-arch Business Uses cases Capabilities cloud culture Data Architecture Enterprise Architecture health checks IoT maturity openstack Requirements Services strategy System Use Cases techical debt train44ir Use Cases Values visual models

    Blogs about

    AgileEA Process Blogs Charity Cloud Openstack Enterprise Architecture Health checks Information & Data Modelling Strategy Technical Debt Thoughts Use Cases

    Our Twitter Feed

    Copyright: Time 2 Talk CC T/A AgileEa.com, 2006 - 2021.
    Theme by Colorlib Powered by WordPress
    Agile Enterprise Architecture
    Proudly powered by WordPress Theme: Shapely.
     

    Loading Comments...
     

    You must be logged in to post a comment.