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

Blogs

AgileEA Process

Putting the Agile into an EA process (2007)

  • 2008-07-252018-05-08
  • by Charles

Abstract

In March 2007 Charles delivered his first talk about the Agile EA operational process at the Togaf Conference in Cape Town South Africa. Read up on the content here:

http://www.opengroup.org/capetown2007

http://www.opengroup.org/capetown2007/edwards.html

Download

pw2007-Togaf-PuttingThe’Agile’IntoAnEAProcess-V1.1.pdf

AgileEA Process

Building a case for an Agile Enterprise Architecture Process…

  • 2007-02-042018-05-08
  • by Charles

Abstract

This series of papers considers the case for enhancing the good work the Open Group contributors have already produced in TOGAF 8.1 [1], by defining an lean and mean Enterprise Architecture (EA) Practice Process that can be picked up and used with minimal tailoring to get an EA Practice started quickly.  Enterprise Architects starting a new practice say “There is so much to do and so much complexity. Where do we start? How do we move forward in a structured and well defined way, but still add value to the organisation quickly?”

The goal of this second paper is to suggest using existing standards to drive out solutions to the problems EA Practices face (as posed in the previous Part 1 paper). To suggest a set of standards upon which an Agile Enterprise Architecture Process could be more specifically defined. Processes to help Enterprise Architects get started quickly and easily.  Enhancements to the TOGAF process are to be based primarily on the newer and beneficial thinking Agile and Adaptive [10] principles, but on other influences as well.

Download

This can be downloaded in PDF form here: Agile Entperise Architecture V1.0 – part 2

AgileEA Process

Agile EA Operational Roles

  • 2008-04-262018-05-08
  • by Charles

Abstract – Agile EA Operational Roles

The subject of People’s jobs, Positions and Roles always tend to get somewhat confusing as there are such subtle differernces between them. However roles are useful in defining activities and responsibilities for those activities, so they need to be defined.

This paper explores each type and offers suggestions for how to organise an Agile Enterprise Architecture team based along the lines of Roles, but keeps the concept of positions and jobs.

Download

Version 1.00 can be downloaded here: Enterprise Architecture Practice Roles

AgileEA Process

Pub menu analogy for AgileEA

  • 2008-08-232018-05-08
  • by Charles

Abstract

How does anyone coming in fresh, not having seen this Enterprise Architecture Operational Process before, start to get into understanding what the AgileEA operational Process is all about?

This paper gives an analogy we all understand; a Pub Menu. This leads you into an equivalent choices in AgileEA so that you get the general idea of what the phases and capabilities within the process are and how to configure them to suit your own situation.

Download

This paper can be downloaded in PDF form from here: PubMenuAnalogyForAgileEA-v0.01.pdf

Thoughts

My work values

  • 2008-07-252018-05-08
  • by Charles

Abstract

Based on a great book I read recently called “Lost in Translation” by Nigel Green, et al. (see: https://en.wikipedia.org/wiki/VPEC-T ) which describes the concept of VPEC-T, I took the Values part out and decided to list my own Work Values.

I came up with this list. What does you list look like? What drives you at work? What goes thought but never spoken often? Careful 🙂

If we each had one of these we might understand why we have conflict in certain areas, which we could then work at resolving.

Introduction

The first letter V in VPEC-T stands for ‘Values’ and is often an overlooked concept in resolving conflicts between people on projects or at work generally, because people have various built in Values which their experience and interactions has shaped over time.

I took the concept and set out my own work values, which I have since given to people in the teams I work with and I’m interested to see if this has an impact in how we work going forward.

Values

This was spawned to measure my own work related Values using the VPEC-T [[1] and [2]] way of thinking.

Have Fun – be relaxed – stay healthy
  • Play hard / work hard. – Time for work and a Time for play.
  • Try and remain cheerful all the time.
  • Don’t take yourself too seriously
  • Avoid letting untenable situations continue – try and resolve them
    • Resolve tensions and conflict.
    • “Cards on the table.”
    • Understand values – where everyone is coming from – we are all different? (Hence this document)
  • To meet communicate below.
  • To meet “care don’t stress” below.
Improve
  • Build a better easier world so there is more time for fun.
  • Want to make things better, improve the overall experience.
  • Maximise the efficiency of a process or service. (over time).
  • Minimise the effort required to execute a process or service (over time).
  • We have a company principle of working efficiently and effectively.
  • To meet have fun – be relaxed – stay healthy above.
Keep it simple stupid (KISS)
  • The easier and simpler processes are the more likely they are to succeed and be effective.
  • Converse: The more complex it is the less likely it is to succeed and be effective.
  • We have a company principle based on the Keep it as simple as possible concept.
  • To meet improve above.
  • To meet care don’t stress below.
Organise
  • Want to organise things and ensure there is
    • A known place for things and (Structure is sound)
    • A known way of working for doing things (Behaviour is sound)
  • Use technology to guide and support rigour
    • To minimise human error
  • To meet improve above.
Communicate
  • Spend slightly more time ensuring everyone is on the same page, than working in continual chaos.
  • A verbal “stitch in time saves nine.”
  • To meet Organise above.
Plan short term detail
  • Make the best progress in the short term within the framework of the long term view.
  • Don’t rush into things, cool calm collected thought – without procrastination.
    • “More speed less haste”, “Steady as she goes”, “There they go – diving into detail”
  • Don’t just muddle / meander on from day to day.
    • Just leave it up to every one to just do their own thing.
    • “Don’t make your bad planning my problem” = plan
  • We have a Company principle of Offering Value for Money.
  • To meet Organise above.
  • To meet Communicate above.
  • To meet ‘plan long term high level’ next.
Plan long term high level
  • Define a high level Vision and set of goals and objectives.
  • Work within this long term framework.
  • Make the best progress toward the long term view by controlled short term planning.
  • If necessary – based on learning from the short term feedback – go back and change the Long term vision
  • To meet Organise above.
  • To meet Communicate above.
  • To meet ‘plan short term detail’
Embrace change
  • Accept change is inevitable.
  • Always plan far enough ahead to be able to accommodate change.
  • To avoid wasting time on ‘organise’ above.
  • To meet improve above.
Manage and Control Change
  • Plan around the unknown => Risk and opportunity management.
  • Ensure changes do not waste short term planning effort.
  • i.e. Only plan short stints into the future within long term framework.
  • Allow the long term view to change.
  • To meet both plan’s above.
  • To meet embrace change above.
Refine iteratively
  • Learn from feedback
  • Plan – do – review regularly.
  • To meet organise above.
  • To meet communicate above.
  • To meet improve above.
  • To meet embrace change.
  • To meet manage change above.
  • To meet rigour below.
Human interaction
  • Casual over formal.
  • Say it like it is, in a diplomatic way.
  • Look at it from their point of view – “Spend a day in another person’s shoes”
  • Accept the differences between people and the way they do things.
  • We have a company principle based on being Open and transparent.
  • To meet communicate above.
  • To meet have fun – be relaxed above.
Rigour
  • Rigorous with an acceptable degree of fluctuation.
    • Many tools in a toolbox, to choose from and between.
    • You choose to use only a particular set of tools (don’t have to do all)
    • Each tool uses the same rigour.
    • i.e. Doesn’t mean just do as we feel at the time
  • Be agile in the short term, but work toward a bigger long term goal
  • To meet manage and control change
Care don’t Stress
  • Too much stress is bad for your health.  Life is too short to stress.
  • Stress does not facilitate changing things, it entrenches them.
  • Caring helps change things because it takes a positive approach.
  • We have a company principle of doing great work because we love what we do.
  • Care enough to push for what you believe in appropriately.
  • To meet pay the mortgage.
  • To meet have fun – be relaxed above.
  • To meet “Improve” above.
Pay the mortgage
  • Of course this aspect is the reality check and might change decisions a little!
  • Always difficult to decide to tell it like it is and know you will be marched off the property!
  • At some point however – a decision has to be made as to “flog a dead horse” vs. “move on”, knowing you have given it your best.
  • To meet embrace change.
  • To meet “care don’t stress.”

Conclusion

These are my work values, what are yours? If we understand our fundamental differences firstly at a personal level, then at a team level then at a project and business level, we will have more chance of success in our projects working.

 

References
[1] VPEC-T comes from the book by Green Nigel, et al. “Lost in translation.”

[2] https://en.wikipedia.org/wiki/VPEC-T

 

 

Posts navigation

1 … 3 4 5 6 7 … 9

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
    Copyright: Time 2 Talk CC T/A AgileEa.com, 2006 - 2023.
    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.