Friday, August 21, 2015
Friday, March 22, 2013
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).
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).
Monday, March 11, 2013
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.
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.
Sunday, March 10, 2013
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.
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.
Saturday, March 2, 2013
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.
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.
Saturday, July 2, 2011
Which definition of IT Architecture (EA) is correct?
Architecture is a governance discipline from COBIT (4.1). COBIT definition gives us:
From the father of Architecture Zachmann, we get:
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:
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.
Wednesday, May 25, 2011
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.
Thursday, April 21, 2011
Open-source a new marketing channel for your company!
The open-source community can be a new market channel for your company. Do you want your product to get noticed? You can use open-source attributes when marketing your product. You don't need commercial support on your software products, but you can use the the open-source channel to reach new customers. Your software company don't need to follow success example like JBoss, MySQL, eZ Publish, ZOPE and Trolltech. What's important her is your new market channel and at the same time the possibility to give back to the community.
Tuesday, April 5, 2011
Our use of database tools
For application development for build, tests, and debugs PL/SQL packages, procedures, triggers, and functions we use TOAD (http://www.toadsoft.com/toad_oracle.htm).
The TOAD-application comes both as a freeware and commercial solution. With the TOAD application developer can create and edit database objects such as tables, views, indexes, constraints, and users. TOADs SQL Editor provides an easy and efficient way to write and test scripts and queries, and its powerful data grids provide an easy way to view and edit Oracle data. TOra (http://tora.sourceforge.net/) and SQL Nexus (http://www.codeplex.com/sqlnexus) are tools that help the developer to identify the root cause of SQL Server performance issues. TOra is open-source and SQL Nexus is commercial products. Both tools can dramatically reduce the amount of time spend manually analyzing data. TOra is definitely one of the most mature open-source applications TOra is defined as a multi-platform database management GUI that supports accessing most of the common database platforms in use. Today TORa is a well-known standard for Nets developers.
The TOAD-application comes both as a freeware and commercial solution. With the TOAD application developer can create and edit database objects such as tables, views, indexes, constraints, and users. TOADs SQL Editor provides an easy and efficient way to write and test scripts and queries, and its powerful data grids provide an easy way to view and edit Oracle data. TOra (http://tora.sourceforge.net/) and SQL Nexus (http://www.codeplex.com/sqlnexus) are tools that help the developer to identify the root cause of SQL Server performance issues. TOra is open-source and SQL Nexus is commercial products. Both tools can dramatically reduce the amount of time spend manually analyzing data. TOra is definitely one of the most mature open-source applications TOra is defined as a multi-platform database management GUI that supports accessing most of the common database platforms in use. Today TORa is a well-known standard for Nets developers.
Monday, March 28, 2011
100% Open Source test environment?
With software testing we check the quality of our product. Our software model is Agile which often employ test driven development and place an increased portion of the testing in the hands of the developer, later it can reach a formal team of testers.
Before we used a more traditional model, where most of the test execution occurs after the requirements have been defined and the coding process has been completed.
Our test environment is based on open-source test libraries like JUnit, HtmlUnit, JMeter and others. For traditional functional testing we use Fitnesse and Selenium.
Wednesday, March 23, 2011
What do you use for version control?
Version control lets us track files over time. Nets old standard was CVS, today subversion is the standard. The GIT solution has been evaluated but is not formally approved by the architect forum. It is also important to note that Novell (yes we are using SLES Linux) at this moment does not support GIT packages. It's possible to download GIT packages from kernel.org and from Novell’s build cluster (software.opensuse.org).
CVS has been used longer than subversion, and no new projects are using CVS. Nevertheless you will see that the CVS disk footprint still is the biggest part.
Operation developers use subversion in some projects (where subversion/svn has been installed) running their scripts on the different NFS file servers. The code from the operation developers is also included with common source code tree.
CVS has been used longer than subversion, and no new projects are using CVS. Nevertheless you will see that the CVS disk footprint still is the biggest part.
Operation developers use subversion in some projects (where subversion/svn has been installed) running their scripts on the different NFS file servers. The code from the operation developers is also included with common source code tree.
Problems with license mangement?
In practice open-source software is generally free or cheap to acquire, and the licensing regime is not onerous either to administer or to fund. Commercial software, by contrast, does not distribute its source code, and generally requires ongoing payments in respect of licensed software, which must be administered and calculated according to the terms of the licenses. With commercial software you also lose your control over your business code. In most cases support and service is slower than support and service you may get from the open-source communities.
Tuesday, March 22, 2011
Which application server (java) should you use…?
We have seen that companies have based their IT infrastructure around two platform types:
• Proprietary middleware stack (IBM, BEA, Microsoft, Oracle etc)
• Open-source software (often Linux, Apache, MySQL and Perl/Python/PHP; referred to as the LAMP).
We have had very negative experience with JAVA EE-application servers, like IBM WAS (WebSphere Application Server) and its ESB implementation (Enterprise Service Bus). JEE has traditionally been a path to vendor lock-in even though specifications are free and open. We feel this has led us to the recommendation to avoid application server dependencies. This, in turn, has led us to a server solution based on the open-source servlet containers Jetty and Tomcat. The idea behind ESB did not fit our demands properly and instead we based our architecture on a simple single database message poll solution, and various other integration techniques.
It has proven difficult to find an open-source project with a level of customization and functionality to match the requirements for this architecture. Therefore Nets has developed an Java library (core-proxy), and will in the future provide this as a contribution to the open-source community as free software.
• Proprietary middleware stack (IBM, BEA, Microsoft, Oracle etc)
• Open-source software (often Linux, Apache, MySQL and Perl/Python/PHP; referred to as the LAMP).
We have had very negative experience with JAVA EE-application servers, like IBM WAS (WebSphere Application Server) and its ESB implementation (Enterprise Service Bus). JEE has traditionally been a path to vendor lock-in even though specifications are free and open. We feel this has led us to the recommendation to avoid application server dependencies. This, in turn, has led us to a server solution based on the open-source servlet containers Jetty and Tomcat. The idea behind ESB did not fit our demands properly and instead we based our architecture on a simple single database message poll solution, and various other integration techniques.
It has proven difficult to find an open-source project with a level of customization and functionality to match the requirements for this architecture. Therefore Nets has developed an Java library (core-proxy), and will in the future provide this as a contribution to the open-source community as free software.
Open-source code is not only for idealists!
Today we find the environment for open-source code is not only for idealists. A company using open-source also has the possibility to buy support and help using the software better. We see today a lot of wealth creation in connection with services based on open-source. For the different companies using open-source we see better control, less errors and better services
.
.
Thursday, March 17, 2011
Which IDE (Integrated Development Environments) are you using?
Java developers in Nets today are using Integrated Development Environment (IDE) tools. The main two tools in use are Eclipse and IntelliJ IDEA. Eclipse is a free open-source tool and IDEA is not. Since we use Maven as the build tool, every developer is free to choose which IDE he uses, since Maven will ensure that we have no dependencies on proprietary to build, package or deploy our software. Eclipse is the most used IDE, but IDEA is popular in some departments. We estimate that 80% of the developers use Eclipse, and the rest is mostly using IDEA.
Monday, March 14, 2011
76% of our code is open-source code
Over a six month period we (Nets=old BBS) analyzed usage of open-source (code) by collecting data from 12-14 large development projects based on Java. Most of these projects have been initiated in connection with the Stay project. We have extracted the following vital statistical data from these projects
The source code deployed:
• In house developed source code (including libraries)
• External open-source code (including libraries)
• External closed source code (including libraries)
The result was amazing, data shows that approximately 76% of code is open-source code, less than 7 % is closed external code, and 17% is developed in-house. The external code is reduced day by day as we convert our old code from WAS (WebSphere Application Server, from IBM ) to Jetty.
The source code deployed:
• In house developed source code (including libraries)
• External open-source code (including libraries)
• External closed source code (including libraries)
The result was amazing, data shows that approximately 76% of code is open-source code, less than 7 % is closed external code, and 17% is developed in-house. The external code is reduced day by day as we convert our old code from WAS (WebSphere Application Server, from IBM ) to Jetty.
Wednesday, January 12, 2011
IT strategy and IT Architecture Frameworks are too much based on Business strategy and Business Architecture.
Today both IT strategy and IT Architecture Frameworks are too much based on Business strategy and Business Architecture. One makes this as prerequisite architecture activity that needs to be undertaken, if not catered for already in other organizational processes (enterprise planning, strategic business planning, business process re-engineering, etc.). But is this smart when one expect that the business strategy will last much longer than the IT strategy?
Christian Wig has some interesting remarks:
“When people tell me that the IT strategy should be 'driven' by the business strategy, I normally tell them that their underlying paradigm is fundamentally wrong. Or I ask them to provide me with a business strategy having a 10 years’ time perspective, which - of course - never exists (and never should exist). Or, I tell them that if we meet again 10 years from now, in the same boardroom of the same company, that they will be highly frustrated by how the IT architecture of the 2020s actually prohibits business development - driven by the 'business-driven' IT decisions we made together back in 2010.
This paradox is a quite critical one facing most businesses today: The technology platform that supports their business areas, products and processes have a much longer life-span than the business strategies which the technology is supposed to support. And at the same time, no technological platform will be 'prepared' for handling anything that wasn't explicitly foreseen and planned for. So the ability to look around the corner, and actually plan for the unplanned, is what I really focus on.”
Christian Wig has some interesting remarks:
“When people tell me that the IT strategy should be 'driven' by the business strategy, I normally tell them that their underlying paradigm is fundamentally wrong. Or I ask them to provide me with a business strategy having a 10 years’ time perspective, which - of course - never exists (and never should exist). Or, I tell them that if we meet again 10 years from now, in the same boardroom of the same company, that they will be highly frustrated by how the IT architecture of the 2020s actually prohibits business development - driven by the 'business-driven' IT decisions we made together back in 2010.
This paradox is a quite critical one facing most businesses today: The technology platform that supports their business areas, products and processes have a much longer life-span than the business strategies which the technology is supposed to support. And at the same time, no technological platform will be 'prepared' for handling anything that wasn't explicitly foreseen and planned for. So the ability to look around the corner, and actually plan for the unplanned, is what I really focus on.”
Monday, January 3, 2011
Is it possible to manage the enterprise architecture without implementing architecture principles?
From the Open Group (http://www.opengroup.org/architecture/togaf8-doc/arch/) we find the following definition of different principles. Depending on the organization, principles may be established at any or all of three levels:
Enterprise principles provide a basis for decision-making throughout an enterprise, and inform how the organization sets about fulfilling its mission. Such enterprise-level principles are commonly found in governmental and not-for-profit organizations, but are encountered in commercial organizations also, as a means of harmonizing decision-making across a distributed organization. In particular, they are a key element in a successful architecture governance strategy (see Architecture Governance).
Information Technology (IT) principles provide guidance on the use and deployment of all IT resources and assets across the enterprise. They are developed in order to make the information environment as productive and cost-effective as possible.
Architecture principles are a subset of IT principles that relate to architecture work. They reflect a level of consensus across the enterprise, and embody the spirit and thinking of the enterprise architecture. Architecture principles can be further divided into:
o Principles that govern the architecture process, affecting the development, maintenance, and use of the enterprise architecture
o Principles that govern the implementation of the architecture, establishing the first tenets and related guidance for designing and developing information systems
These sets of principles form a hierarchy, in that IT principles will be informed by, and elaborate on, the principles at the enterprise level; and architecture principles will likewise be informed by the principles at the two higher levels.
Enterprise principles provide a basis for decision-making throughout an enterprise, and inform how the organization sets about fulfilling its mission. Such enterprise-level principles are commonly found in governmental and not-for-profit organizations, but are encountered in commercial organizations also, as a means of harmonizing decision-making across a distributed organization. In particular, they are a key element in a successful architecture governance strategy (see Architecture Governance).
Information Technology (IT) principles provide guidance on the use and deployment of all IT resources and assets across the enterprise. They are developed in order to make the information environment as productive and cost-effective as possible.
Architecture principles are a subset of IT principles that relate to architecture work. They reflect a level of consensus across the enterprise, and embody the spirit and thinking of the enterprise architecture. Architecture principles can be further divided into:
o Principles that govern the architecture process, affecting the development, maintenance, and use of the enterprise architecture
o Principles that govern the implementation of the architecture, establishing the first tenets and related guidance for designing and developing information systems
These sets of principles form a hierarchy, in that IT principles will be informed by, and elaborate on, the principles at the enterprise level; and architecture principles will likewise be informed by the principles at the two higher levels.
Is Maven still the best build tool?
We use Maven as build tool; it handles and centralizes all build, dependencies, reporting and documentation. Since we do not rely on restricted software and do not deploy our applications into a javaEE environment we can package our software with all dependencies included. Maven is configured to build a zip archive of our servers with all configuration included ready for installation on any server using simple Unix and Linux commands. Maven does not lay any restrictions on which IDE the developers use.
Wednesday, November 24, 2010
Problem supporting all the different versions of Java and libraries?
The Java language has undergone several changes. In addition to the language changes, much more dramatic changes have been made to the Java class library over the years, which have grown from a few hundred classes in JDK 1.0 to over three thousand in J2SE 6.0. We have also seen entire new APIs, such as Swing and Java2D, have been introduced. Many of the original JDK 1.0 classes and methods have been deprecated. A consequence of this is that companies have to support different versions of java. I in some organization this is becoming a problem. The result may be that an application server is supporting many different versions of Java from JDK 1.4 to 1.x. Each application may have different standard for use of Java, libraries, deployment etc.
Subscribe to:
Posts (Atom)