Slopen onder Architectuur (Document)

Zojuist vond ik een document genaamd "Slopen onder architectuur".

Ik vind het een verfrissend document vooral omdat het ons het eens totaal ongebruikelijk architectuurprincipes laat lezen.

Ik vraag me alleen af in hoeverre er echt aandacht voor dit onderwerp gewenst is. Definieren we niet altijd de gewenste situatie en bepalen we niet daarna niet zoals het veranderingstraject? Dat een architectuurverandering vaak leidt tot een stuk vervaning en daarmee sloop lijkt mij vanzelfsprekend.

Voor mij is het vanzelfsprekend dat er vanuit een beheer perspectief altijd goed gekeken wordt naar de hoeveelheid onderhoud dat nodig voor bepaalde deelsystemen. En dat wanneer dit niet meer acceptabel is gekeken wordt naar een oplossing hiervoor. Dient hier echt seperaat vanuit de architectuur discipline aandacht voor te zijn? Vooralsnog lijkt mij dat een symptoom van het ontbreken van de juiste procedures die zouden moeten voortvloeien uit principes over eenvoud, flexbiliteit en onderhoudbaarheid.

Wat denk jij?

Het betreffende pdf-document kun je hier vinden.

Alle modellen op een rij

Opzoek naar de juiste manier om jouw idee over te brengen?

Als je de volgende website hebt bezocht niet meer!

Wedden dat je hem meteen aan je favorieten toevoegd, net als ik?

Klik hier om snel te gaan kijken.

eBooks verzameling / collection

Zojuist vond ik een website met daarop een interessante publiekelijk beschikbare verzameling van eBooks van onder andere Microsoft boeken maar ook Cisco en andere bekenden.

Zie: http://book.itzero.com/ voor bijvoorbeeld...

Altijd handig om bij de hand te hebben.

SOA In the real world

Een prachtig 'boek' over de concepten en de praktijk van SOA kun je hier downloaden.

Wat mij betreft een 'must read' voor iedereen die niet weet wat SOA is en een 'should read' voor iedereen die met SOA te maken heeft.

Plan van aanpak (sjabloon)

Een goed Nederlands sjabloon voor een plan van aaanpak voor het ontwikkelen van een informatiesysteem kun je hier downloaden (bron: zbc.nu).

Sterk punt van dit sjabloon is dat ieder hoofdstuk een inleiding heeft, hier en daar voorbeelden en tips worden gegeven maar dat het toch een heel beknopt en praktisch sjabloon is gebleven.

Uit de inleiding

Het standaard plan van aanpak, dat in dit artikel is weergegeven, heeft met name betrekking op de ontwikkeling van informatiesystemen.Daarnaast is het dermate generiek, dat het ook voor andersoortige trajecten gebruikt kan worden. De specifieke detailpunten kunnen dan enigszins afwijken.


De inhoudsopgave (samenvatting)

0. Management samenvatting
1. Introductie
2. Projectopdracht
3. Aanpak
4. Projectinrichting en voorwaarden
5. Plannen
6. Kwaliteitsborging
7. Overige plannen
8. Bijlagen

Project Start Architectuur Sjabloon (DYA)

Het sjabloon "Project Start Architectuur" als onderdeel van de architectuur methode "DYA" van Sogeti kun je hier vinden (pdf).

Een publiek beschikbaar uitgewerkt voorbeeld heb ik helaas nog niet kunnen vinden.

Uit de inleiding

Dit document bevat de project start architectuur voor het project . De PSA wordt gemaakt om te waarborgen dat nieuwe ontwikkelingen enveranderingen in samenhang worden gerealiseerd en passen binnen de toekomstiggewenste informatievoorziening. De PSA is de vertaling van de totale architectuurnaar de specifieke situatie van het project.

De inhoudsopgave

1 PROJECT
1.1 Inleiding
1.2 Doel project
1.3 Business drivers
1.4 Architectuur drivers

2 BUSINESS ARCHITECTUUR
2.1 Afbakening
2.2 Projectoverstijgende ontwerpkeuzen
2.3 Architectuurrichtlijnen

3 INFORMATIE ARCHITECTUUR
3.1 Afbakening
3.2 Projectoverstijgende ontwerpkeuzen
3.3 Architectuurrichtlijnen

4 TECHNISCHE ARCHITECTUUR
4.1 Afbakening
4.2 Projectoverstijgende ontwerpkeuzen
4.3 Architectuurrichtlijnen

5 BESLUITEN
5.1 Business architectuur
5.2 Informatie architectuur
5.3 Technische architectuur

6 ARCHITECTUUR AFWIJKINGEN
6.1 Business architectuur
6.2 Informatiearchitectuur
6.3 Technische architectuur

IBM's Referentie Architectuur - Best Practices (RUP)

Een prachtig inleidend document over referentie architectuur in het algemeen en de relatie met RUP in het bijzonder; door IBM.

http://www.ibm.com/developerworks/rational/library/2774.html

ICT is onbelangrijk!

Ken je dat gevoel: je komt bij een organisatie binnen en je hebt het idee dat alles zoveel beter en efficienter kan maar je krijgt geen voet aan de grond. Je praat als Brugman, je haalt voor je gevoel alles uit de kast maar niets lijkt te werken.

Grote kans dat de manier waarop jij tegen I.C.T. aankijkt compleet verschillend is dan die van de "Business". Niet voor niks is het artikel "IT Doesn't matter" uitgeroepen tot het beste artikel van Harverd Business Review aller tijden.

Door het lezen en begrijpen van dat artikel is het eenvoudiger om de zaak ook eens van de andere kant te bekijken en daardoor kun je beter een brug te slaan (een van de taken van een Architect).

Het artikel kun je hier vinden.

De belangrijkste conclusies, die volledig door de "Business" worden onderkend:

• geef minder geld uit aan ict;
• volg de markt maar loop niet voorop;
• richt je op gevaren niet op kansen;

Biztalk Architectuur in een notendop

Heb je dadelijk een gesprek met een Biztalk-ontwikkelaar maar heb je daar tot op heden nog nooit iets mee gedaan?

Lees dan snel het volgende artikel om snel grip te krijgen op de basisterminologie en basisarchitectuur.

http://www.codeproject.com/KB/biztalk/BiztalkToGrandma.aspx





Succes!

Componenten zijn concepten

Bij architectuur gaat het om concepten!

Ik beschouw de volledige architectuur van een systeem als een groot concept. En omdat zo'n architectuur is opgebouwd uit (logische)componenten beschouw ik deze als deelconcepten.


Mijn ervaring leert dat de voordelen om een (logisch)component te introduceren als een op zichzelf staand concept zeer groot zijn, namelijk:

• Mensen (klanten, sponsors, collega's etc.) worden makkelijk enthousiast van een concept. Denk maar eens aan het alternatief: een lange droge lijst met features;


• Concepten zijn precies voldoende abstract om als uitgangspunt te dienen voor de functionele en technische uitwerking.

Maar waar zou zo'n concept nu aan moeten voldoen? Wat zou een formele definitie van zo'n architectuur-deelconcept kunnen zijn, vroeg ik me vandaag af?


Opeens moet ik aan de standaard (ANSI1471) 'architectuurdefinitie' denken: "The fundamental organization of a system, embodied in its components, their relationships to each other and the environment and the principles governing its design and evolution".


Volgens mij zijn dat precies de eisen die je aan zo'n concept moet stellen:

• Verduidelijking van de logische plaats in het geheel door het benoemen van de relaties met andere componenten en zijn omgeving;
• Verduidelijking van ten minste een principes betreffende het ontwerp en evolutie.

Ook moet ik denken aan de IEEE1471 definitie van een 'architectuurbeschrijving': "... The architectural description can be divided into one or several views. Each view covers one or more stakeholder concerns. View is defined as “a representation of a whole system from the perspective of a related set of concerns”...."Op basis hiervan kunnen we een derde formele eis benoemen, namelijk geschreven op een manier die aansluit op de belevenis van de klant voor wie we dit doen.


Een voorbeeld: het logische component "Logging"


Je zou kunnen zeggen voor logging gebruiken we de Microsoft Enterprise Library. Maar van Logging kun je ook een concept maken namelijk.



=====

Ontmoet Marcel's Logging!


Marcel's logging is gebaseerd op de ervaring van jarenlange softwareontwikkelervaring die wij inmiddels hebben opgedaan. Zo leert de ervaring ons dat het verstandig is om onderscheid te maken in rollen en soort. Bijvoorbeeld technische informatie voor de systeembeheerder en technische informatie voor de ontwikkelaar. Maar ook bedrijfskundige informatie waar alleen de "business analyst" iets aan heeft. Gegevensinhoudelijke waarschuwingen bijvoorbeeld.


De staat van de betreffende applicaties worden steeds op een dashboard middels stoplichten getoond. Bij oranje of rode stoplichten kan direct op het probleem worden ingezoomd.
Normaal gesproken staat de gehele applicatie in een diagnosestand (met alle gevolgen voor snelheid en gebruiksvriendelijkheid) of niet. Maar bij onze loggingstrategie is het mogelijk om per zogenaamde sessie deze diagnosestand aan te zetten.

Ook voor onze logging geldt het principe: technologie moet uitwisselbaar zijn en we beginnen met de Enterprise Library.Technologie is nu eenmaal een van de meest veranderlijke zaken (anticipation of change).

Verder dient het afhandelingsproces vrij inregelbaar te zijn. Bij een bepaalde freqentie van bepaalde fouten moet geëscaleerd worden totdat ze bevestigd zijn. In andere gevallen is een email naar bijvoorbeeld de supportdesk voldoende. Welke gevallen welke route bewandelen is iets wat in de loop van de tijd steeds duidelijker wordt (lerende organisatie)In de flexibele afhandeling dient een extern systeem te kunnen worden aangeroepen zodat er automatisch een issue kan worden aangemaakt in het issuetrackingsysteem.

===

Nabeschouwing

• Blijkbaar was het belangrijk voor de klant om de ervaring te borgen;
• Het is duidelijk hoe het component gebruikt gaat worden in zijn omgeving;
• Het is duidelijk hoe het component samenwerkt met andere componenten;
• Het is duidelijk hoe het component zich gedraagt;
• Het is duidelijk welke principes van toepassing zijn;
• De conceptuele beschrijving kan uistekend dienen als uitgangspunt voor de verdere uitwerking.

Microsoft Infrastructure Optimization (Maturity) Model

Zojuist kwam ik op technet een interessant "maturity model" voor de infrastructuur tegen. Ik vind dit model vooral interessant van wegen zijn "no-noncense" karakter dat ook prima dienst kan doen in een niet-infrastructuur context.


Bron: http://technet.microsoft.com/nl-nl/infrastructure/bb870589(en-us).aspx

Voorbeeld van de "no-nonsense" beschrijving:

Basic: “We Fight Fires”

The Basic IT infrastructure is characterized by manual, localized processes; minimal central control; and nonexistent or unenforced IT policies and standards regarding security, backup, image management and deployment, compliance, and other common IT practices. There is a general lack of knowledge regarding the details of the infrastructure that is currently in place or which tactics will have the greatest impact to improve upon it. Overall health of applications and services is unknown due to a lack of tools and resources. There is no vehicle for sharing accumulated knowledge across IT. Customers with Basic infrastructure find their environments extremely hard to control, have very high desktop and server management costs, are generally very reactive to security threats, and have very little positive impact on the ability of the business to benefit from IT. Generally, all patches, software deployments, and services are provided high touch and high cost.

Customers benefit substantially by moving from this type of Basic infrastructure to a Standardized infrastructure, helping them to dramatically reduce costs through:

• Developing standards, policies, and controls with an enforcement strategy.
• Mitigating security risks by developing a "defense in depth" posture: a layered approach to security at the perimeter, server, desktop, and application levels.
• Automating many manual and time-consuming tasks.
• Adopting best practices, such as those of the IT Infrastructure Library (ITIL); the SysAdmin, Audit, Network, and Security Institute (SANS); and so on.
• Aspiring to make IT a strategic asset rather than a burden.

Does This Sound Like You?
Find out how to make your Basic infrastructure more Standardized.

Instructie video's van Microsoft

Hieronder een overzicht van instructievideo's van Microsoft gericht op de beginnende Software Architect.


Transitioning from a developer to an architect

http://msevents.microsoft.com/cui/eventdetail.aspx?EventID=1032338980&culture=en-CA

Are you a developer who would like to learn more about becoming an architect? Or how to get formally recognized as one (since you already wear the design and architecture hat along with the developer one)?. Join Mohammad Akif for the fourth and last part of the series focused on aspiring architects, during this session we will discuss how you can attain the skill set required to be an architect and sell yourself as an architect within your organization and industry. We will also provide a list of resources that you can use to continue the transition from a developer to an architect role.


Architecture 101

http://msevents.microsoft.com/cui/eventdetail.aspx?EventID=1032338971&culture=en-CA

Agenda

• Types of architects
• Role of an architect
• Why become an architect
• When not to become an architcet
• Attributes of an architect
• What an architect is expected to know
• How to ben an effective architect

Omschrijving

Architecture is the balance between art and engineering, it requires a certain mindset and approach to solving problems. Architects often function as a bridge between the business users and development groups and are increasingly being recognized as a critical community within organizations. Becoming an Architect can often translate in to an elevated status from a career stage perspective but it is hard to find prescriptive guidance around how to become an architect. Join Mohammad Akif for the first of a four part series focused on aspiring architects. During the Architecture 101 session we will discuss some key ideas around Architecture and define attributes of an architect.

Software development lifecycle and methodologies

http://msevents.microsoft.com/cui/eventdetail.aspx?EventID=1032338974&culture=en-CA


Over the years the various approaches teams have used to develop software have evolved. Join Dave Remmer in the second of a series focused on aspiring architects where we will discuss the various stages projects go through and sample some of the methodologies used by teams developing software. In this session we will compare and contrast the waterfall, agile, RUP, Scrum and MSF methodologies and how they are used within software projects.



Services orientation and other architectural paradigms

http://msevents.microsoft.com/cui/eventdetail.aspx?EventID=1032338978&culture=en-CA


One of the hottest topics in software architecture is the services oriented approach to building solutions and how this can provide agility, flexibility and reuse. Join Dave Remmer in the third of a series focused on aspiring architects where we will be looking at approaches to architecting software. This session will give an overall description of service orientation and how it differs from object oriented and component based architectures as well as a discussion of some of the organizational challenges teams experience when using a services oriented architecture.

IIdentifierCreationService must be installed

Tijdens het werken met Workflow Foundation kreeg ik de volgende foutmelding in de DesignTime omgeving:

To prevent possible data loss before loading the designer, the following errors must be resolved: The service 'System.Workflow.ComponentModel.Design.IIdentifierCreationService' must be installed for this operation to succeed. Ensure that this service is available.

De oorzaak was achteraf eenvoudig: ik had het project niet als een workflow project aangemaakt maar als een normale "class library". Volledig decleratief had ik de workflow opgebouwd en om deze dan toch in de designer te kunnen bekijken dient het projecttype te worden veranderd. Dit doe je door in een texteditor de projectfile aan te passen (doe een unload van het project en met een rechtermuisklik selecteer je edit projectfile).

De volgende regel moet worden toegevoegd aan het "<project><propertygroup>" element:

{14822709-B5A1-4724-98CA-57A101D1B079};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}

Highlevel Microsoft Workflow mogelijkheden

Als ik slechts een onderwerp mag noemen waar ik het meest in geinteresseerd ben dan is het het ontwikkelen van "State of the art" administratieve systemen (natuurlijk gebruik makend van Microsoft Technologieen) die deels of geheel via het internet worden gedistribueerd (lees: kort-door-de-bocht SaaS).

Bij het ontwikkelen van zo'n "State of the art" systeem kan Microsoft Workflow Foundation natuurlijk niet ontbreken.

Vanuit een architectuurperspectief kan het nuttig zijn om van Microsoft Workflow Foundation het volgende te weten:

• Je kunt je eigen activities ontwikkelen;
• Je kunt je eigen workflowtypes ontwikkelen (dus naast de standaard 'statemachine' en 'sequential' types) want workflowtypes zijn zelf ook maar gewone 'activities';
• Workflows kun je niet alleen definieren via 'xaml' en via de designer maar vanuit je eigen applicatie via een speciale API. Dit is in het bijzonder interessant voor een SaaS oplossing omdat klanten dan via de webbrowser op een gebruiksvriendelijke en eenvoudige manier in dezelfde omgeving eenvoudige worfklows kunnen definieren (Visual Studio is hier dan vaak geen oplossing).
• Specifieke instanties van een worfklow kunnen ad-hoc worden aangepast terwijl ze nog 'running' zijn. Dit is bijzonder interessant zeker in een zogenaamde 'human workflow' maaromgeving. Bijvoorbeeld: "In dit specifieke geval wil ik dat de juridische afdeling hier hun goedkeuring op geeft".
• Workflow Foundation ondersteunt transacties.
• Workflow Foundation biedt een uitgebreide 'audittrail' waarmee precies kan worden achterhaald wat de levencyclus van een workflowinstantie is/was en waarom. En - hoe kan het ook anders - als de standaard 'audittrail' niet voldoende informatie biedt dan kun je hier je eigen uitbreidingen voor ontwikkelen.

Gratis tijdschrift: "The Architecture Journal"

Als het als een Architect praat, denkt en kleedt dan is het ook een Architect!

Iedereen die het abieert om Software Architect te worden doet er dan ook goed aan om zich onmiddelijk te abonneren op het gratis tijdschrift van Microsoft "The Architecture Journal" (ja ook gratis in je bus in Nederland).

Er is tevens een mogelijkheid om "oude" nummers gratis na te bestellen, doen dus!

Verder zou ik alle "oude" nummers, ook die niet meer kunnen worden nabesteld, een voor een goed doorlezen.

Zie http://msdn.microsoft.com/arcjournal

Succes!

Business Business Business!

Als Architect werk je op de grens van Business en Techniek.

Op basis van mijn ervaring schat ik zomaar in dat jij als toekomstige Architect perfecte technologischekennis hebt en dat je deze kennis continue up-to-date houdt.

Maar hoe ziet het met jouw Businesskennis?

Ook je bedrijfskundigekennis moet goed zijn en goed blijven en dat gebeurt natuurlijk niet zomaar. Net zoals in de techniek komen en gaan trends en is jargon aan de orde van de dag. Daarnaast is er vanzelfsprekend een schat aan informatie over hoe de meest voorkomende bedrijfsproblemen op te lossen (business patterns! we denken wel vaak dat wij met onze situatieuniek zijn maar zijn het slechts zelden).

Harvard
Daarom is mijn advies: koop elke maand, of beter nog abonneer jezelf op het Harvard Business Review tijdschrift (bij steeds minder kiosken te koop maar zeker op Schiphol) en bovendien de Harvard Business Review OnPoints. (Klik hier voor de laatste editie)

Meld je bovendien onmiddelijk aan om de "Executive Summary" van elke nieuwe editie maandelijks per email te ontvangen. (Klik hier)

Op deze manier heb je snel weer een uitstekende stap gezet om een Architect te worden en te blijven. Mijn ervaring leert dat zeker na een jaar de voordelen onmiskenbaar worden.

Succes!