Accessed here www.AgileEA.com

changes in this release are:

• Added The Segment Archicture View
• Refined the Project View
• Added a new Principles
• Added new Tasks to do with the inception phase (Gathering Business Processes, Applications, technology and Infrastructure items for the repository)
• Ensured Diagrams were displaying correctly for the inception Phase
• Added Logical Data Model
• Added Business Domain Object Model
• Renamed some of the Inception Work flow Items

Accessed here www.AgileEA.com

changes in this release are:

• Refined the Why not TOGAF paragraph on "What is AgileEA?" page.
• Added a Role called "People Change Manager" in the People Management Discipline.
• Added a Concept called "People Perception change management" as a to do place holder.
• Added a Task called "Manage People's Perceptions"
• Added a Capability Pattern called "Manage People Change"

Accessed here www.AgileEA.com

changes in this release are:

• Added a task in the planning discipline called "Define an iterative planning process"
• Added a Work product called "Iterative planning contract"
• Renamed the role "EA Sprint planner" to "EA Iteration / Sprint planner"
• Added the task "Plan the next iteration"
• Added the task "Retrospectively examine the iteration"
• Added a collective role called "EA Practice team"
• Moved the Publish Vision and mission into the Communications discipline.
• Moved the "Edit Iteration activities" to the Change Control discipline and renamed it to "Manage Work Item activity changes"
• Renamed the "EA Sprint Activity Backlog list" to "EA Workitem / Activity Backlog list"
• Added the task "Evaluate Practice Maturity"
• Added the workproduct outcome called "Maturity level measurement"
• Added the template placeholder for "Maturity Assessment Criteria"

Accessed here www.AgileEA.com

changes in this release are:

• Downloaded and converted the AgileEA Library to the new epf-composer 1.2.0
• created a new banner picture that spans 1600pixels across the whole top of the screen.

Accessed here www.AgileEA.com

changes in this release are:

• Updated the Whitevideos page to allow downloads (this was overwritten by the camtasia presentation)
• Worked on the layout of the Inception Phase Activity diagram.
• Added all the Capability patterns for the Elaboration Phase (as is)
• Added all the Capability patterns for the Architecture-as-usual Phase (as they are currently)
• Worked on the layout of the Elaboration Phase Activity diagram.
• Worked on the layout of the Architecture-as-usual Phase Activity diagram.
• Juggled the "Manage Risk" with "Define an Arch Risk Process" between Inception and Elaboration.

Accessed here www.AgileEA.com

changes in this release are:

• Created the Whirl Wind Tour Of Agile EA - Part1 Video
• Created the Whirl Wind Tour Of Agile EA - Part2 Video
• Linked it to the AgileEA.com site
• Created two WiteVideo pages in the Agile Ea process under white videos
• Added a link to each of the 2 pages from the AgileEa.com website to view the Videos.
• Added a link to the Whirl wind tour WhiteVideos from the "What is Agile EA?" page.

Accessed here www.AgileEA.com

changes in this release are:

• Changed the Start_page to have a table of Icons and get rid of the poor image quality of the previous icons.
• Created a Roadmap for "AgileEA overview of the components"
• Added a Phases Content package
• Added an Iteration content package
• Added a Diciplines Content package
• Added a Delivery Lifecycle content package
• Added a Role Content package
• Added a Task Content package
• Added a WorkProduct content package
• Pointed each Icon to the Concept (Phase, Iteration, Discipline, Delivery lifecycle, Role, Activity, Work Product, and Goal Use Case.)
• Refined term Task (from OpenUP)
• Refined term Role (from OpenUP)
• Refined term Discipline (from OpenUP)
• Refined term Phase (from OpenUP)
• Refined term Iteration (from OpenUP)
• Refined term Delivery Lifecycle (from OpenUP)
• Refined term Workproduct (from OpenUP)
• Updated the Goals of EA Operations section - removed the diagram as it was duplicated and replaced it with a textual description.
• Added more detail to Capability_Business_Use_cases.
• Included a link to the Iteration planning guidelines from what is an Iteration.
• Removed the duplicate assumption called Scope of EA definition.
• Added supporting material on EA Disciplines with the EA Discipline pictrure scaled down to 600 x 404.
• Lined this supporting material to what is a Discipline concept.
• Fixed errors on the introductory page called "What is EA"

Accessed here www.AgileEA.com

changes in this release are:

• Created separate Packages under "Referenced Material" such as Assumptions, Principles, Roadmaps and moved items there from one large package.
• Wrote more in the Assumptions items.
• Fixed spelling mistakes found.
• Added a new Concept: "Assumption: EA is Business Demand driven over IT Supply driven"
• Refactored all the Principles and Practices into one Logical grouping, instead of many individual items under the Start View.
• Renamed the Business-as-usual to Architecture-as-usual
• Added a new Concept: "Assumption: This Process starts EA at the very beginning"
• Added Checklist: Joining AgileEA - What Processes are already in place?
• Linked this checklist to the concept above.
• Added ER Diagramming Notation to the list of Notations
• Added a separate Notation package
• Moved all Notation items into this new package.
• Created a package called EA_Goals_and_Capabilities and moved Capability guidelines into it
• Added a Concept: What is a Phase? from OpenUP (modified - not extended at this stage - will worry about this later)
• Defined a Concept: "Assumption: EA Practice as a Department or a Project"
• Linked the above two
• Defined a Concept called "Feasibility_Phase" described it and linked to Milestone
• Defined a Concept called "Inception_Phase" described it and linked to Milestone
• Defined a Concept called "Elaboration_Phase" described it and linked to Milestone
• Defined a Concept called "Architecture-as-usual_Phase"

as to do and linked to Milestone

Accessed here www.AgileEA.com

changes in this release are:

• Refactored The Method Content Packages into three main packages, Management_content, Foundation_content and Architecture_content.
• Created a Segment_architecture content package within the Architecture_content.
• Moved the 'EA_Project_involvement' package's contents into Architecture_content, mainly the Segment_Architecture package.
• Deleted the EA_Project_involvement content (for now) this is more of a View than a content placeholder.
• Renamed the Start_View Package to Referenced_material
• Created the "Define Central Directory Structure" task under Configuration management
• Defined a WorkProduct - outcome - "Defined Directory Structure".
• Removed a bug - An Extraneous link to a referenced lifecycle which was unnessesary and confusing.
• Added more information to the Configuration Management tool mentor
• Moved "Establish a Taxonomy" task from Process and Tools to Core Architecture
• Added task: "Automate Change Control lifecycles"
• Removed Workproducts for conciseness: "Existing Business Documentation", "Existing Information Documentation", "Existing Technology Documentation"
• Defined a Fundamental Concept called: "Assumption: Enterprise Architecture builds up a Knowledge Base"
• Refined the Concept called "Assumption: Pragmatic Approach"
• Ensured all Assumptions were displayed - one was missing.

Accessed here www.AgileEA.com

changes in this release are:

• Worked on the Inception Phase Capabilities
• Added definitions for the term Ontology
• Added definitions for the term Domain Ontology
• Renamed Task from 'Define meta-Architecture' to 'Define WorkProduct Meta-Model'
• Changed the Business Use Case Model diagram
• Added a page in the wiki for each Capability pattern in the EPF model for refining and discussing text
• Enhanced the "Define a Mission" Task. Added Steps, descriptions, etc.
• Enhanced the "Define a Vision" Task. Added Steps, descriptions, etc.
• Deleted the previous folder in the Inception Capability section.
• MOved the order of the Vision and Mission below the Principles and Standards because of a dependency.

Accessed here www.AgileEA.com

changes in this release are:

• Concentrated on working in the Inception Phase.
• Removed the multiple Milestones and created one Milestone with multiple checkpoints.
• Added an Inception Milestone Checklist
• Linked this checklist to the Inception Phase.
• Refined the Iteration textual details.
• Defined a new Method Content Package called Inception_planning
• Moved the Inception Phase diagram over to the left as it was too far right.
• Created a Feasibility Milestone Checklist.
• Linked it to the feasibility Phase page.
• Edited the Iteration page to remove the detail that should have been in the Milestone Checklist.
• Put a link to the Feasibility Milestone checklist on the Iteration page.
• Enhanced the EA_Practice_Lifecycle page - added key considerations, staffing and purpose info.
• Renamed the "instantiation_planning" Method Content Package to "feasibility_planning"
• Moved the "feasibility_planning" and "Inception_planning" into the "planning" Method Content Package.
• Created a "Elaboration_planning" sub package in the "planning" Method Content Package.
• Created an "Architecture-as-usual_planning" sub package in the "planning" Method Content Package.
• Created an Elaboration Milestone checklist and linked it to the EA Practice lifecycle Milestone.
• Created an Architecture-as-usual Milestone checklist and linked it to the EA Practice lifecycle Milestone.

Accessed here www.AgileEA.com

changes in this release are:

• Renamed the WorkProducts, Guidelines and Tasks from 'Mandate' to 'Proposal'
• Created a new Method Content Package called 'Instantiation Planning'and moved relevant items into it for Feasibility.
• Also renamed the Capability from 'Mandate' to 'Proposal'
• Enhanced the Feasibility Milestone.
• Added detail into the Feasibility iteration.
• Renamed the 'Business-as-usual' Phase to 'Architecture-as-usual'
• Filled in more of the Proposal Work Product structural contents.
• Generally enhanced the Feasibility Phase Workproducts, Tasks and Roles
• Enhanced the Diagrams attached to the Feasibility Phase.
• removed Existing Business Documentation out of the list of WorkProducts (cluttering them up with info that exists anyway)

Accessed here www.AgileEA.com

changes in this release are:

• Separated out the Whatepapers section (background structural change).
• Added in the Whitepaper on using UML guided by BMM to model business motivation.
• Modified the list of contributers into three categories (from two) at the bottom of each page.
• Linked to the Wiki from the bottom of each page asking for collaboration.
• Added a Link to the WhiteVideos
• Rearranged the order of the Start View to put WhitePapers and WhiteVideos at the bottom.
• Added a link to WhiteVideos from What is EA Page.

Accessed here www.AgileEA.com

changes in this release are:

• Proved that the Video from You Tube could work being embedded in the Wiki and the EPF site.
• Created a Welcome to Agile EA Video, upload it and linked to it from within the EPF website and the Wiki.
• Added the concept of White Video's and used this one to prove the point.

• Made changes to the introductory pages
• Added Start page - with links to
• Added descriptions and definitions of Enterprise Architecture
• Added a page called What is Agile Enterprise Architecture which gives an overview
• Added Assumptions list to the Start View

• It is represented by value points along its length
• The value points are ordered
• It is independent of all other dimensions

and (arguably)

• It is a continuum, such that any interval between value points can be subdivided meaningfully.

Only some of the dimensions in the canidiate list (e.g. Time) fulfil these criteria, others patently do not (e.g. Zachman interrogatives). I have three questions related to this:

1. Do we, as enterprise architects, care - or is this just an academic nicety?
2. If we do care, are the concepts which aren't dimensions important (I'd suggest that they are)?
3. If they are, then what are they, conceptually, and how do they relate to the other types of 'dimension'?

I think that Principles are universal, and therefore do not split up easily between Internal and External to an organisation. On that basis they should be stand alone Principles that relate to Directives and Influencers. (almost influencers on influencers if that makes sense?)

I've edited my previous post to have the correct URL. Try it again.

Also check out this thread - you might find it interesting too: BMM Principles

Also I could even consider them being a type of "Directive" at the same level as Business Policies & Rules.
I am 60-40 here, so a preference for internal influencer.
What do you think?

I have extended the standard bmm in the diagram on this page: business motivation model class-diagram showing relationships to show
where I would see Principle and best practice being linked into the existing concepts.

Do you agree with this logic?

Kostas Tsatsaris

I'd be interested in your comments (other than the fact that 1. The dependency arrows lines shouldn't be so dotted more dashed, and 2. They join every thing to everything else.)

Check out Business Motivation Modelling too, its good logical stuff which I contend we should be modelling in the EA space!

See related thread on BMM here

If not why not?

If so what length are the iterations/sprints?

For the rest I didn't understand your point about Goal or Objectives. Could you give an example of what you mean by this?

I am extremely impressed and think its the most sense the computer industry has made in a long time.
Well done to those who came up with it!

It is also a nice easy language to use wihtout tools, etc. and is by implication therefore be very Agile in nature.

The only concept I see missing (which may be there but not obvious) is the conept of a Goal or Objective. I would tend to use the object you use for Value to show Goal and have Value as something slightly different. This would then align to the Business Use Case Concept at a very high level of abstraction.

here: http://www.telin.nl (english version)

Is there an English URL or paper that describes Archimate Modelling Language we can look at? After a quick browse it all seemed to be in Dutch? (I might have missed something)

ArchiMate is now actively used by over 50 different organizations and is supported by several commercial tools and consultancy organizations.
More information can be found on: http://archimate.telin.nl

Also defined a high level directory structure based upon the logic in the paper.

Just for your information we have released the next update of the Agile EA Process.

Main additions are:

• White paper on Scrum planning process under white papers section in Start.
• Additions of capabilitities in the Feasibility and Inception phases.

a) I agree - Solution Architects who know about the latest technology could be brought into an EA Practice to establish the "To Be" Future overall Reference Architecture for the Enterprise (as opposed to doing so for a particular project) - To me this is a Solution Architect in the role of overall Enterprise Architecture.

b) I don't agree with calling a person who will work on a Project establishing a new Architecture as a Solution Architect, being called an Enterprise Architect. - To me this is a Solution Architect in the role of Project Architecture for an Enterprise.

They obviously want a Solutions Architect in the Enterprise context.

It would be really nice if we could get our own definitions is order so that the rest of the industry could use them. It leads to all sorts of misunderstandings and mis-alignments of concepts. I personally think this is one of the reasons for establishing Process webs, so that the terminology starts becoming more standard.

Does anyone else have any strong feelings about this type of thing?

CE Fully agree and good point - I'll work on that as part of my 2nd Paper (maybe a third) on the
website.

In agile software development you
are focusing on the final product — i.e. a software product that will be
used by business for some useful purpose (hopefully). In agile enterprise
architecture, the end product (which, of course, is never actually "done")
is a set of models that (hopefully) allows the business to make informed
decisions about how best to adapt to change. So, agile software development
results in a product while agile enterprise architecture results in models.
Interesting slant on it. While you are not wrong - I was thinking more along the lines of the EA
converging the Business 'Products'. Products being some models, but also physical and tangible
implemented 'Business Processes', 'Software' and 'Hardware'. If done in isolation could diverge, if
done with the big picture in mind have more chance of converging.
Given the general aversion to modeling in the agile community, this could be
a problem.

Yes - agreed. If we push more for the Product angle this may alay their fears somewhat. Even if
conceptually the models describe the actual end products that are built in an Agile manner. Both before
and after the fact. i.e. If the Goals of the Agile Dev projects are driven by the thinking of the EA team
based upon their own models, then the implementation on the ground could still be largely done in an
Agile manner.

If agile EA is about producing models, but "agilists" don't like
models (which is a overreaching stereotype, of course), then what useful
thing does agile EA "build"?

To me - even though we produce models, the Agile Product developers do not necessarily consume
these models. They consume the output from them, Goals and requirements that Coordinate the
spawning of Projects. The consume or at least have to reconcile with the Reference Architectures they
have to build to (ok so that’s a model), but they don’t need to change it, just use it for understanding
and input to their work. They consume the requirements at

• a Business Arch level to work with Business Processes A,B and C.
• At an Information Systems Arch level they get to work with Information service L,M & N, and
• at Technology Arch level to use DB x, ESB y, Server z, etc.

If fact, there might be a large number of
"agilists" that think the whole idea of EA could never be agile (Big Design
Up Front thing).

There's the rub. The whole point of doing EA in an Adaptive manner is to build the design as we go
(just like they do) but not for one specific Product, for the whole collection of Products = Enterprise.
The Agile Dev Team for on Project only need to focus on their Product for their Project. EA focuses on
the glue between the Projects and Teams for the Collection of Products.

In particular, I think the first two principles of the Agile Manifesto don't
quite apply as written (or could result in misunderstanding). While it is
important to value "individuals and interactions over processes and tools",
we may need to be cautious about how this applies to agile EA, since EA is
quite a bit about understanding your business processes and how they map to
your technology platform (i.e. the "tools" that automate the business
processes). And since quite a bit of EA is about governance, there is a need
for process (how formal is another question). Perhaps this first principle
could be to value "Informed business stakeholders over reference models" or
something…

Yes - good point. Especially since the Models and repository in the early stages of an EA would not be
nearly as well defined or up to date as the knowledge of the users. I guess if you get really good at it
there will come a point where the knowledge base in the repository would be more accurate than any
one stakeholders individual knowledge (but that’s still an ideal right now!)

Second, "Working software over comprehensive documentation" might be better
restated for agile EA as "Useful architecture models over pretty pictures"
(i.e. no Visio or PowerPoint). I do think EA has run the danger of creating
too much "comprehensive documentation", but in many cases the bigger problem
is that the "comprehensive documentation" isn't very easy to use (because
it's often a pile of Word documents, Visio diagrams, and PowerPoint
presentations).

Yep - that’s exactly the problem we (where I work) have right now! Made worse by the fact that older
documents contradict newer ones, etc. Boils down to having the right EA Toolset which integrates to
the Asset repository of the Enterprise, etc.

I think a clear definition of what it means to be "agile" at enterprise architecture needs some more attention. In agile software development you are focusing on the final product — i.e. a software product that will be used by business for some useful purpose (hopefully). In agile enterprise architecture, the end product (which, of course, is never actually "done") is a set of models that (hopefully) allows the business to make informed decisions about how best to adapt to change. So, agile software development results in a product while agile enterprise architecture results in models.
Given the general aversion to modeling in the agile community, this could be a problem. If agile EA is about producing models, but "agilists" don't like models (which is a overreaching stereotype, of course), then what useful thing does agile EA "build"? If fact, there might be a large number of "agilists" that think the whole idea of EA could never be agile (Big Design Up Front thing).

In particular, I think the first two principles of the Agile Manifesto don't quite apply as written (or could result in misunderstanding). While it is important to value "individuals and interactions over processes and tools", we may need to be cautious about how this applies to agile EA, since EA is quite a bit about understanding your business processes and how they map to your technology platform (i.e. the "tools" that automate the business processes). And since quite a bit of EA is about governance, there is a need for process (how formal is another question). Perhaps this first principle could be to value "Informed business stakeholders over reference models" or something…

Second, "Working software over comprehensive documentation" might be better restated for agile EA as "Useful architecture models over pretty pictures"
(i.e. no Visio or PowerPoint). I do think EA has run the danger of creating too much "comprehensive documentation", but in many cases the bigger problem is that the "comprehensive documentation" isn't very easy to use (because it's often a pile of Word documents, Visio diagrams, and PowerPoint presentations).

Anyway, my two cents…

Thanks, Chris ~:|

If we are to speed up the creation of an EA Process, it would be quicker to Extend the existing base processes, such as Change Management, Configuration management, Project planning, Environment disciplines and other RUP/OpenUP type categorizations in an EA context. What do you think?