Succesvol software ontwikkelen (Agile)

Slechts sporadisch kom je een boek tegen dat zo praktisch en zo realistisch beschrijft hoe je succesvol software zou kunnen ontwikkelen dat je niet kan begrijpen dat dit niet veel eerder bestond.

Dit is dus ook het geval met het boek "Getting Real". Hierin staat dit op een werkelijk fantastische manier in 16 actiegerichte hoofdstukken beschreven.

Voor iedereen die met softwareontwikkeling te maken heeft een echte aanrader en voor iedereen die ambities heeft een eigen softwarebedrijfje te beginnen een absolute must!

Het boek is volledig publiekelijk beschikbaar. Zie: 37signals.com

(Bedankt voor de tip Gerard Doeswijk)

Architectuur zonder Architectuur!

De afgelopen tijd is het onderwerp architectuur echt een hype geworden en het einde is nog lang niet inzicht: nooit eerder werden er zoveel seminars over dit onderwerp gehouden. Nooit eerder werden er meer boeken en artikelen over dit onderwerp gepubliceerd.

Maar waarom eigenlijk?
Is architectuur nieuw? Dat toch zeker niet.
Is architectuur een doel? Ook dat toch niet.

De belangrijkste reden voor al deze aandacht voor dit onderwerp heeft te maken met het feit dat iedereen dagelijks geconfronteerd wordt met de gevolgen van slechte en toevallig tot stand gekomen structuren. Denk bijvoorbeeld aan eilandautomatisering en het ratjetoe aan verschillende technologieën die van project tot project gebruikt zijn. Om nog maar niet te spreken van de totaal verschillende bouwstijlen die gehanteerd zijn van ontwikkelaar tot ontwikkelaar en van project tot project.

Logisch dus dat er totaal geen sprake is van synergie tussen de verschillende projecten. Dat het beheer op langere termijn een onmogelijke taak is. Dat inwerktijden de spuigaten uitlopen en dat het maken van aanpassingen zolang duurt dat niemand het meer wil en durft uit te leggen. Dat dus de ICT een blok aan het been is van menige organisatie en dus niet de bedrijfsstrategie ondersteund laat staan aanvult is logisch.

Aan de ontwikkelaars lag het zeker niet. De zeer goed opgeleide en ervaren ingenieurs die doorgaans de projecten realiseren begrijpen maar al te goed welke keuzes er moeten worden gemaakt en wat de consequenties daarvan zijn. Ze doen dat alleen steeds vanuit hun eigen projectdoelstellingen en vanuit hun eigen ervaringen.

Aan de acceptatietesters lag het ook niet: zij controleerden keurig of de applicatie werkt zoals het moet als het wordt opgeleverd. Wat er op de achtergrond gebeurd en hoe dat is ingericht kunnen en willen zij natuurlijk niets van weten.

De oorzaak is eenvoudig: vanuit het IT Management zijn er nauwelijks inhoudelijke eisen gesteld aan de manier waarop de verschillende projecten *inhoudelijk* werden uitgevoerd en die paar eisen die wel werden gesteld kwamen vaak niet verder als het dicteren van welke versie van Visual Studio en SQL Server er gebruikt moest worden en heel af en toe zelfs een zogenaamde Coding Standard. Misschien begrijpelijk want de projecten schoten als paddenstoelen uit de grond en nieuwe technologieen boden zich sneller dan ooit aan.

Nee, bij kleinere automatiseringsafdelingen is het juist de IT Manager die de meeste kennis heeft van de organisatie als geheel en het IT landschap bovendien en daarom is juist hij bij uitstek de juiste persoon om zich hiermee bezig te houden.

IT Managers, laat de architectuurkaas niet van je brood eten!

Start vandaag met het inhoudelijk opstellen van wat tijdens de beruchte seminars populair 'beleid' wordt genoemd. Zorg dat je weet op wat voor soort veranderingen je wilt inspelen en hoe (denk aan adaptief/perfectief/proactief onderhoud) . Oja, vergeet ook niet om te testen of dergelijke veranderingen echt beter te realiseren zijn. Want als er een ding is wat we de afgelopen periode hebben geleerd dan is dat het wel.

Want architectuur is iets waar je niet al te veel over moet praten,

het is iets wat je gewoon moet doen.

"Sharepoint Search" Instructievideo's

Op de volgende website is een op indrukwekkende verzameling van publieke Sharepoint instructievideo's te vinden.

Zie: http://www.english-tiger.com/Training/Default.aspx


De instructievideo's bestaan uit 14 modules:

• Module 1 - IntroductionThis module introduces the full three-day class.



• Module 2 - Enterprise Search OverviewThis module provides some astounding figures as to why organizations require Enterprise Search Solutions! We recommend that you do not skip this module.



• Module 3 - SharePoint Search WalkthroughThis module is more than an overview. It cuts through the marketing hype in an informed, intelligent manner! We recommend that you do not skip this module.



• Module 4 - Search Architecture and DeploymentThis module provides essential insights, discussions, and very deep technical information on architecture and server layouts.



• Module 5 - Crawl and Query ProcessesThis module provides the 'under-the-hood' story about what happens at crawl and indexing time, and follows up with essential information about the query-time processes. This is how Search in SharePoint actually works, regardless of what you see in the user interfaces.



• Module 6 - Relevance RankingIf relevance ranking is perceived to be inaccurate by your users, they will simply stop using your solutions. This module explains in detail how you can tune the relevance ranking subsystem.



• Module 7 - Customizing the End-User ExperienceThis module shows you ALL that can be achieved by customizing Search Center in Microsoft Office SharePoint Server 2007, without requiring additional development effort. It is the definitive guide to customizing Search Center.



• Module 8 - Developing Search SolutionsWhere Search Center cannot be customized sufficiently to suit your needs, you might need to develop your own solutions. This module shows you how! Developer topics include the KeywordQuery syntax, the FullTextSQLQuery syntax, the Search object model, the Search Web service, and the Search Administration object module.



• Module 9 - Business Data Catalog SearchThis module shows you how to set up BDC search from scratch. It also highlights some common pitfalls.



• Module 10 - Extensibility and Integration for SearchThis module provides more information about the crawl and indexing process by focusing on iFilters and Protocol Handlers. It also discusses full and incremental crawls, as well as providing guidance around 32-bit/64-bit architecture.



• Module 11 - Search AdministrationThis module provides a comprehensive discussion of search administration.



• Module 12 - Security for SearchThis module covers a variety of topics from search accounts, through Information Rights Management, to crawling Forms-based authenticated sites.



• Module 13 - Performance, Scalability, and Capacity PlanningThis module provides invaluable discussions of indexer requirements, query server requirements, and other scalability approaches. Most importantly, it discusses how you can plan disk space requirements for indexing large corpuses.



• Module 14 - Search OperationsThis module concludes the class by discussing operations and management tasks for enterprise search solutions.

Architectuur is de oplossing, maar wat was het probleem?

Als Architect kom je maar al te vaak in een situatie dat je moet uitleggen wat een Architect doet en wat de voordelen van Architectuur zijn.

Als je, net als ik, hiervoor een presentatie mag maken dan komt de volgende presentatie van het IMN (Informatie Management Nederland) je vast goed van pas!

De presentatie is in twee delen opgebouwd:
- Deel 1 geeft de algemene lijn van de IMN visie op architectuur-toepassing weer
- Deel 2 gaat concreet in op het gebruiken van de IMN-visie bij het toepassen van architectuur voor een specifieke probleemsituatie





Klik hier voor de PowerPoint.

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!