Great place for free opensource EA modelling tools, also BPMS (Business Process Management System). Posted by Saif Mohammad. http://www.saifikram.com/2014/04/opensource-enterprise-architecture-modelling-tools

What's your organization's maturity in enterprise architecture?

Do your organizations manage change effectively? How is your development processes? Are you on the level – Don’t know what you don’t know.  
 
Architecture Immaturity:  
 
- Don’t have any architecture  
 
- It’s all complexity and inconsistency, with much system duplication  
 
- High cost for all changes  
 
Initial Awareness:  
 
- Most people know that they need architecture  
 
- Conceptual (Visio), weak standards, no formal underpinning  
 
- Used by some projects, but no systematic influence  
 
Do have the level formal Architecture – Architecture as specification?  
 
- Formal models and specifications based on industry standards  
 
- Integrated and actionable  
 
Last level Meta-Architecture – Overall architecture conforms to architecture  
 
- Formal meta-models based on industry standards  
 
- Tools, automation, traceability, consistency  
 
More information about maturity from The Open Group:  
 
http://pubs.opengroup.org/architecture/togaf8-doc/arch/chap27.html  
 
NB: The maturity levels is based on Mike Rosen (Applied TOGAF).

What's the use of architectural principles when nobody remembers them?

Architecture principles are based on business principles. We all know this is critical in setting foundation for architectural governance.  
 
The architecture principles should capture the fundamental truths about how enterprise will use and deploy business and IT resources and assets.  
 
These principles are typically developed by Lead Architect with CIA, Architecture Board, and other business stakeholders.  
 
What we see is that EA-teams don't use a day or two on this activity but months. The result are often to many architecture principles that nobody remember.  
 
Business Principles  
 
1) Primacy of Principles  
 
2) Maximize benefit to the Enterprise  
 
3) Information Management is Everybody's Business  
 
4) Business Continuity  
 
5) Common Use of Applications  
 
6) Compliance with law  
 
7) IT Responsibility  
 
8) Protection of Intellectual Property  
 
Data Principles  
 
1) Data is an Asset  
 
2) Data is shared  
 
3) Data is Accessible  
 
4) Data Trustee  
 
5) Common Vocabulary and Data Definitions  
 
6) Data Security  
 
Application Principles  
 
1. Technology Independence  
 
2. Ease of Use  
 
3. Requirement based change  
 
4. Responsive Change Management  
 
5. Control Technical Diversity  
 
6. Interoperability  
 
Below you find some sample on architecture principles:  
 
University of Canberra  
 
https://guard.canberra.edu.au/policy/policy.php?pol_id=3235  
 
If your company has many business principles try to limited this to fewer architecture principles. Three to ten architecture principles are possible for the IT department to remember. If you have too many principles there is also less flexibility in your architecture.

Are you thinking of taking the TOGAF foundation or certified test and looking for more information?

You will find hundreds of training providers that offer TOGAF® 9 training for certification. The cheapest alternative is self-study.  
 
The link below gives a brief introduction to TOGAF:  
 
http://www.cmnogueira.pt/2013/03/12/an-introduction-to-togaf/  
 
The link below gives you The Open Group TOGAF® Standard Courseware V9.1 Edition:  
 
http://www.togaf.info/  
 
General information from The Open Group about TOGAF exams you will find in the two links below.  
 
TOGAF 9 Part 1 Exam Summary  
 
www.opengroup.org/togaf9/cert/docs/og91.html  
 
TOGAF 9 Combined Part 1 and Part 2 Exam Summary  
 
www.opengroup.org/togaf9/cert/docs/og93.html  
 
The Open Arc has made a list of TOGAF® 9 tests examples. These are a collection of test you can do to practice your TOGAF® 9 knowledge and were built simulating a real TOGAF® 9 Part 1 and Part 2 exam. Be ware that there test material is not written by The Open Group but by a team of TOGAF 9 certified architects, for more detail check there web site:  
 
http://theopenarch.com/81-tests/72-togaf-9-exam-tests.html  
 
The Open Arc portal is to spread Enterprise Architecture best practice and offer free enterprise architecture resources.  
 
You will lots of information around TOGAF from Udayan Banerjee home page. He has also made some TOGAF® 9 Part 1 and Part 2 exam. Be ware that there test material is not written by The Open Group:  
 
http://setandbma.wordpress.com/2011/03/31/togaf-foundation-level-certification-another-practice-test/  
 
Chris Eaton has made TOGAF® 9 Part 1 and Part 2 exam. Be aware that there test material is not written by The Open Group:  
 
http://chriseaton.wordpress.com/2009/08/24/togaf-9-certification-multiple-choice-questions/  
 
I hope these links will help you.  

TOGAF strengths and weaknesses (published March 1. 2013 in www.cw.no)?

I forbindelse med virksomhetsarkitektur har metodeverket TOGAF fått en stadig mer sentral rolle… Mange større bedrifter har sertifisert sine ansatte i rammeverket TOGAF (The Open Group Architecture Framework) fra The Open Group. Men hvor mange bruker dette metodeverket i praksis? Vi prøver å oppsummere de mulighetene og begrensingene som finnes i TOGAF-rammeverket. 
  
Hva er TOGAF? 
The Open Group Architectural Framework (TOGAF) er et åpent rammeverk for enterprise arkitektur. The Open Group er for de fleste mest kjent for sertifisering av Unix operativsystemet, som er et godt eksempel på en åpen standard. TOGAF er utviklet og vedlikeholdt av The Open Group Architecture Forum. Første versjon kom ut i 1995 og er opprinnelig basert på det amerikanske forsvarets rammeverk TAFIM (Technical Architecture Framework for Information). TOGAF-dokumentasjonen er fritt tilgjengelig på nettet. 
 
Hva inngår i TOGAF-rammeverket? 
Sentralt i TOGAF er ADM (Architecture Development Method)-metoden og Enterprise Continuum som består av «Best Practice» gjenbrukbare arkitektur komponenter. Man kan se på Enterprise Continuum som et referansebibliotek for enterprise arkitektur utøvere og andre interessenter. Foruten ADM og Enterprise Continuum har TOGAF ressurser og referanser knyttet til forskjellige teknikker, metoder og løsninger som kan brukes til både planlegging og gjennomføring av virksomheten sin arkitektur. 
 
Hva er TOGAF ADM? 
ADM (Architecture Development Method) er prosessen som brukes for å analysere en hel organisasjons eller et spesifikt område i organisasjonen. Den viktigste grunnen til å anvende ADM er for å kvalitetssikre at de riktige prosjektene starter opp med de tilhørende endringsplanene for både forretning og de underliggende IT-systemene. Ved hjelp ADM får man fram de spesifikke forretnings- og virksomhetsbehov. ADM består av ti faser. 
 
 
 
 
Figur 1: TOGAF ADM. 
 
Man kan kjøre Iterasjon gjennom hele ADM syklusen, iterasjon mellom ADM fase og en eller flere andre ADM-faser. Det er også mulig “besøke“ tidligere ADM-faser. Det er mulig å ha flere prosjekter som samtidig kjører gjennom ADM med synkronisering mellom prosjektene. 
 
TOGAF og begrensinger 
En stor fordel med TOGAF er at det er en åpen standard tilgjengelig for alle og hvor alle har muligheten til å bidra. Men åpenheten og de mange bidragsyterne kan igjen gi inkonsistenser i dokumentasjonen. Når det er mange som bidrar er det viktige å være enig om de samme konseptene. TOGAF er ikke et modelleringsverktøy eller et kvalitetssystem men er der som et verktøysett som du kan tilpasse til din organisasjon. Rammeverket har tidligere vært brukt av offentlige organer i USA det ligger derfor mye erfaring bak. 
 
En svakhet med TOGAF er den omfattende dokumentasjonen og at ikke alt vil ha praktiske nytteverdi for alle virksomheter. Mange ser på TOGAF som for akademisk og teoretisk, og mangel på praktiske eksempler i TOGAF-dokumentasjonen styrker dette synet. Størst nytte vil man typisk ha av ADM, Enterprise Continuum, Architecture Capability Framework og maler. ADM er motoren for å kunne få gjennomført arkitekturendringer i et selskap. ADM er også den komponenten i TOGAF som er mest tidløs. Den svakeste delen av TOGAF er referansemodellene. TOGAF sin TRM (Technical Reference Model) som er en “Foundation Architecture” viktigste mål er å sette navn på terminologien som inngår mellom kommunikasjons og applikasjonslaget (SW, applikasjonsplattform og kommunikasjon). III-RM er en teoretisk applikasjonsmodell som har grensesnitt til basale tjenester du finner i et standard operativsystem. Her har tydeligvis folk med operativsystem og nettverk kompetanse bidratt. Det skinner her gjennom at The Open Group har jobbet med Unix sertifisering. Vi kjenner ikke noen prosjekter som har brukt hverken TRM eller III-RM. Grenseløs informasjonsflyt (Boundaryless Information Flow) er et konsept-varemerke beskyttet av Open Group. TOGAF ønsker at alle nødvendige data er tilgjengelige for alle (når som helst) så lenge man har rettigheter til disse dataene. I en organisasjon sitter vi som regel i en silo med begrenset informasjon. Målet for bedriften må være at data kan flyte fra start til slutt av forretningsprosesser (eller verdikjeden), på tvers av avdelinger og forretningsenheter og at alle i organisasjon får tilgang til nødvendig informasjon. TOGAF sier at en utvidelse av infrastruktur- og forretnings-applikasjoner område under TRM, støtter ideen om "Grenseløs informasjonsflyt". Dette vil av de fleste kun bli betraktet som en markeds-jippo.  
 
Flere og flere bedrifter kurser sine ansatte i TOGAF og sier at de skal bruke metoden men praksis viser at mange ikke bruker metodikken. TOGAF skisser en ideell styringsmodell men vi ser at de fleste større bedrifter har som regel en mer kompleks organisasjon som ikke passer sammen med TOGAF sin styringsmodell. Jeg savner eksempler på arbeidsfordeling/ansvar med tilhørende rollespill mellom enterprise arkitekt -funksjoner (både på strategisk og segmentnivå), programleder, forretningsplanlegger, strategiskplanlegger og prosjektstyring. 
 
Endringer av organisasjonen foregår i de siste fasene i ADM-prosessen men i det virkelige liv skjer dette kontinuerlig. ADM prosessen er fleksibel og man vil se at ikke alle bedrifter vil følge den tradisjonelle prosessflyten visjon, arkitektur, muligheter, løsning, styring/gjennomføring. Mange ønsker kanskje å starte med mulighetene først! Hvordan kan endringsledelse være et skritt på slutten av den arkitektoniske prosessen når det skjer hele tiden? Dette er faktisk innebygd i ADM men vanskelig å se. Fase H binder sammen den implementerte arkitekturen fra ADM prosess A-G med neste ADM prosess A-G. For en organisasjon med utviklet enterprise arkitektur kapasitet er dermed prosessen H-A-...-G (-H). Når gjelder fasen «Preliminary» er ikke den med her da den brukes kun når din enterprise arkitektur kapasitet behøver å utvikles eller endres. Integrasjon med andre rammeverk er viktige for TOGAF, metoden ADM skal også kunne tilpasses med andre selskaper sine tilhørende rammeverk. Men hvordan man skal integrere er ikke beskrevet? Her savner jeg rett og slett eksempler på hvordan man integrer med andre rammeverk. enterprise arkitektur verktøy kan være TOGAF sertifisert. Arkitekter kan være TOGAF sertifisert. Men det finnes ikke noe TOGAF sertifisering for selskaper og organisasjoner? Vi har eksempler på bedrifter som hvor de enkelte divisjonene i selskapet er så forskjellige at man strengt tatt ikke kan ha hverken felles IT prinsipper eller IT strategi, de vil derfor ende opp med forskjellige tilpassinger av TOGAF? 
 
TOGAF er forretningsdrevet men IT orientert 
Man fokuserer kun på delene av forretningen som støttes av IT. TOGAF prøver å omfavne forretningsanalyse og forretningsendringer, men er først og fremst ment for å forbedre effektiviteten av IT-støtten for virksomheten. Noen er uenige med TOGAF sin skisserte styringsmodell hvor enterprise arkitekt rapporterer til IT-direktør. Burde enterprise arkitekt rapporterer til adm. direktør slik at man lettere kan knytte arkitektur planlegging til forretningsmessige mål? Enterprise arkitektur ble oppfunnet av IT-avdelingen som et hjelpemiddel for å understøtte forretning bedre. Forretningssiden har aldri bestilt enterprise arkitektur konseptet og spør vanligvis heller ikke om dette (selv om de burde!). For å knytte arkitekturplanlegging til forretningsmessige mål, må virksomheten innse at IT er en del av virksomheten, og at IT arkitektur er en del av virksomhetens arkitektur! 
 
Er du virksomhetsarkitekt eller løsningsarkitekt? 
Vi ser i praksis at de fleste enterprise arkitektene fungerer som løsningsarkitekter, enkeltstående prosjektene blir prioritert fremfor langsiktig mål og strategier. Dette er et stort problem! En viktig verdi for bedriftens enterprise arkitektur i henhold til TOGAF er å komme vekk fra prosjektet tilnærming på forretningsmessige endringer, og få et mer langsiktig perspektiv, som også muliggjør kortere og mindre komplekse utviklingsprosjekter med lavere risiko og større kostnadseffektivitet. En enterprise arkitekt som blir knyttet til arkitektur i et enkelt utviklingsprosjekt i 4 måneder, for deretter å løpe til et annet prosjekt i 5 måneder er sannsynligvis i praksis en løsning arkitekt. Hvis man tar AMD på alvor som metoden for å gjennomføre forprosjekter for endringer, og arbeide etter TOGAF sin Architecture Capability Framework så vil skille mellom en enterprise arkitekt og en løsningsarkitekt være tydelig.

Which definition of IT Architecture (EA) is correct?

Architecture is a governance discipline from COBIT (4.1). COBIT definition gives us:

Enterprise architecture for IT—Description of the fundamental underlying design of the IT components of the business, the relationships amongst them and the manner in which they support the organization’s objectives

From the father of Architecture Zachmann, we get:

A set of design artifacts, or descriptive representations, that are relevant for describing an object such that it can be produced to requirements (quality) as well as maintained over the period of its useful life (change).

The Zachmann framework defines IT Architecture in terms of its goals, the TOGAF framework defines IT Architecture in terms of its contents. A set of design artifacts, that are relevant for describing an object such that it can be produced to requirements (quality) as well as maintained over the period of its useful life (change). The design artefact describe the structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time.

From the famous development frameworks TOGAF the Architecture has two meanings depending upon its contextual usage:

A formal description of a system, or a detailed plan of the system at component level to guide its implementation.
The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time.

osCommerce is a popular Open Source online shop e-commerce solution

Nets business departments are already seeing the benefit of using a complete open-source application for customer use. The osCOMMERCE solution is an example of this. osCommerce is a popular Open Source online shop e-commerce solution that is powered by a dedicated, strong, and ever growing community, and is released under the GNU General Public License. With this software solution you can choose Nets Netaxept (call to Nettsentrisk NTS)and confirm your order. This application was selected by the Nets business department. This is a complete open-source application, not only a java library or tool. Nets have made an integration module which makes it possible for customer to interface the Nets system Netaxept.