Top Community Contributors
Introducing RepoDoc, a document generator for Enterprise Architect
Written by Archimetes
SysML 1.4 reference card
Written by Guillaume
Enterprise Architect User Group: London 2017
Written by DT_Sam
Enterprise Architect identified for Agile Development and DevOps: SD Times In-depth Feature
Written by sparxsystems
Panorama 360 Insurance and Wealth Management Enterprise Business Framework is available on Amazon
Written by Pierre Gagne
RepoDoc, a call for testing
Written by ArchimetesRead more...
We are Profiling EA Users
Written by sparxsystems
Managing a student project with Enterprise Architect - Part 4
Written by doug rosenberg
Birol BerkemGooBiz (Enterprise Architect)
Summary of the presentation (from the EA User Group Meeting at Nuremberg, Oct. 8th 2013)
This animated presentation downloadable below is about the Open Group's TOGAF 9.1 and ArchiMate 2.0 standards. It illustrates on a short case study how to use the ArchiMate ® 2.0 notations throughout TOGAF® 9’ ADM phases until aligning SOA implementation components with changing business strategies and capabilities* using Sparx EA.
The single slide case study is provided using the Balanced Score Cards perspectives to conduct TOGAF 9 / Archimate 2.0 EA Operating Model.
(*) Capability (TOGAF 9.1 Definition) : An ability that an organization, person or system possesses. Capabilities are typically expressed in general and high-level terms and typically require a combination of organization, people, processes and technology to achieve. For example, marketing, customer contact or outbound telemarketing.
- A business capability is a particular ability or capacity that a business may possess or exchange to achieve a specific purpose or outcome - Ulrich Homann - Microsoft
- A business capability defines “what” a business does at its core. This differs from “how” things are done or where they are done (William Ulrich - BPMInstitute.org / OMG's BASIG )
This work by Birol Berkem (GooBiz.com) is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.
Birol Berkem (Ph.D), GooBiz
TOGAF 9 ® and Archimate ® are trademarks of the Open Group.
This animated version of the Goal-Driven Service Oriented Architecture (Goal-Driven SOA) process illustrates on a short case study how companies can capitalize on their business capabilities (*) in order to react swiftly and coherently to changes.
Thanks to its reusable goal-driven business capability components - easily adaptable to changing requirements, the "Goal-Driven SOA" process aims at allowing companies to control execution of their processes and underlying SOA services then adapt them efficiently to targeted situations.
In order to show how to align IT systems to changing decisions, this presentation illustrates a bridge from Business Goals to IT system components using the following steps :
1) Linking business strategies, tactics, processes to IT services and use cases on the basis of business goals in order to propagate changes toward IT system components,
2) Elaborating the Goal-Driven SOA backbone, by transforming functional specifications into corresponding SOA components,
3) Integrating underlying behaviours of SOA components into the Goal-Driven SOA backbone
(*) A business capability is a particular ability or capacity that a business may possess or exchange to achieve a specific purpose or outcome - Microsoft : http://msdn.microsoft.com/en-us/library/aa479368.aspx#servorient_topic3.
For visualizing the animated version of these slides using EA, please download the PPS file below:
This animated short case study of 18 diagram slides presentation illustrates how simple UML and SysML diagrams can be successfully used there to enhance requirement traceability till software architecture layers in order to better dealing with requirement changes using agile methods.
Since a few years, companies try to customize the usage of Agile Methods ( Scrum, XP,...) in order to be able to deliver their products on time and on budget.
One of the serious obstacles they meet using such methods is about informal and untraceable requirement gathering that causes extra costs along iterative development lifecycle.
Gathering requirements on the basis of user stories (or use cases) does not help alone to ensure requirement coverage in face of changes and needs to be strongly driven by the project vision.
This animated short case study of 18 diagram slides presentation illustrates below how simple UML and SysML diagrams can be successfully used there to enhance requirement traceability till software architecture layers in order to better dealing with requirement changes using agile methods.
For downloading the animated version of these slides, please download the ZIP or PPS file below: