|
|
| |
| |
|
Blogs
|
H.J. van Til
|
|
woensdag, 18 augustus 2010 |
Hoe je puree maakt, weet eigenlijk iedereen. Aardappels (of tomaten) worden, ontdaan van schil, gekookt en vervolgens fijngestampt. Tot aardappelpuree, of tomatenpuree. Met appels lukt het ook; in dat geval noemen we de puree moes: appelmoes. Het kan natuurlijk ook ingewikkelder. Door verschillende ingrediënten bij elkaar te voegen, ze daarna gezamenlijk te koken en ten slotte fijn te stampen. Tot puree. En dat noemen we dan hutspot of stamppot; met stamppot boerenkool als oer-Hollands voorbeeld.
Nu is er tegelijk ook een probleem met puree: je moet er niet in terechtkomen. Dat is zelfs spreekwoordelijk geworden! En de vraag is dan ook: hoe blijven we uit de informatie-puree?
 Schrijf als eerste een reactie
|
|
meer
|
|
|
Erwin Oord
|
|
woensdag, 04 augustus 2010 |
|
In een vorig item heb ik betoogd dat de keuze voor een maatwerkoplossing heel verstandig kan zijn in situaties waar je als organisatie jezelf wilt onderscheiden van anderen. De andere kant van het verhaal gaat over ICT-oplossingen voor ondersteunende processen. Daaronder versta ik hier processen die, hoe essentieel ook voor het bedrijf, niets toevoegen aan de identiteit van de organisatie en haar producten. Elke organisatie kent tientallen van dergelijke processen, variërend van het inkopen van kantoorartikelen tot de jaarlijkse beoordelings- en salarisronde voor het personeel. Reacties (1) |
|
meer
|
|
|
Adrian
|
|
donderdag, 22 juli 2010 |
|
What are the Enterprise Architecture Frequently Asked Questions that frequently get wrong answers? Schrijf als eerste een reactie |
|
meer
|
|
|
Adrian Grigoriu
|
|
woensdag, 21 juli 2010 |
|
EA is not in itself about business improvement, technology alignment, strategic planning and portfolio management; EA enables them all though, if properly modelled. As such, to measure Enterprise Architecture value as an EA architect, one needs to evaluate what EA delivers to Enterprise stakeholders, taking into account their views.
Schrijf als eerste een reactie |
|
meer
|
|
|
Danny Greefhorst
|
|
vrijdag, 09 juli 2010 |
|
Ik werd laatst gevraagd of ik kon aangeven wat de juiste omvang is van een bedrijfsservice (ook wel: “granulariteit”). Dat was best een lastige vraag en wel om twee redenen. Ten eerste wist ik niet zeker wat hij bedoelde met “bedrijfsservice”; een dienst die een organisatie levert of een dienst die de software levert en die met bedrijfslogica te maken heeft. Daarnaast is omvang iets dat afhangt van het doel dat je hebt, en waar overigens ook hele andere overwegingen bij gelden voor softwarediensten dan voor organisatorische diensten. Voor softwarediensten kom je al snel in hele technische, maar ook in filosofische discussies en is volgens mij al meer dan genoeg gezegd. Laten we dus eens kijken naar “echte” bedrijfsservices.
Schrijf als eerste een reactie |
|
meer
|
|
|
Wouter Keller
|
|
woensdag, 30 juni 2010 |
|
‘Zaaktypencatalogus, wat is dat nou weer?’, zuchtte het hoofd DIV. ‘We hebben al jaren een DSP, is dat niet gewoon hetzelfde?’ Nee, dat is het dus niet. Ik zal proberen aan te geven waar de crux zit. Kort gezegd: een zaaktypencatalogus (ZTC) is veel ‘levendiger’ dan een documentstructuurplan (DSP). Reacties (1) |
|
meer
|
|
|
Erwin Oord
|
|
vrijdag, 25 juni 2010 |
|
Als je jezelf als architect echt onmogelijk wilt maken, moet je eens proberen om aan het management voor te stellen een maatwerkoplossing te bouwen. Waarschijnlijk valt er even een stilte. Daarna legt een van de aanwezigen kort maar krachtig uit dat die tijden nu echt voorbij zijn, en dan gaat men weer over tot de orde van de dag. Verdere carrièrestappen zijn uitgesloten voor de architect die er klaarblijkelijk helemaal niets van begrepen heeft. Maatwerk is uit de mode. Pakketoplossingen zijn in. Elke zichzelf respecterende organisatie heeft tegenwoordig een lijst met architectuurprincipes, en op al die lijsten staat –ergens bovenaan– het adagium ‘Buy before Build’. Soms nog uitgebreid tot ‘Reuse before Buy before Build’. Reacties (1) |
|
meer
|
|
|
Adrian Grigoriu
|
|
maandag, 14 juni 2010 |
|
I think Gartner makes the good point that there are lots of EA architects wielding influence without having devised in advance an Enterprise Architecture establishing the solution design, investment and decison making contexts.
Schrijf als eerste een reactie |
|
meer
|
|
|
Erwin Oord
|
|
donderdag, 03 juni 2010 |
|
Het is weer verkiezingstijd. Heeft u al een keuze gemaakt? Welke partij gaat het worden? Het is interessant de verkiezingsprogramma’s te bestuderen om te zien welke ideeën partijen hebben over de inzet van ICT en ICT-architectuur. Laat ik u maar meteen uit de droom helpen: het is erg mager. Zoals te verwachten valt, is ICT-architectuur geen onderwerp in de verkiezingsstrijd. De term komt in de verkiezingsprogramma’s niet voor. ICT wordt wel genoemd, zij het sporadisch en niet in alle verkiezingsprogramma’s. Reacties (1) |
|
meer
|
|
|
Erik Vermeulen
|
|
zondag, 30 mei 2010 |
|
Often the best way to express a design is by means of a visual model. There's quite some modeling languages around, to name just a few: Archimate, UML, BPMN, EPC, IDEF, Use case maps, E3value. The complexity of the average language (an important improvement area) forces the architect to look for a tool to support his modeling effort. Architects who don't like the concept of being restricted to a single language and / or tool (a good habit I believe) will not likely invest in expensive tools. Reacties (1) |
|
meer
|
|
|
Marc Lankhorst
|
|
vrijdag, 28 mei 2010 |
|
Musing on a Friday afternoon about the reasons why nearly all large organizations see most of their IT initiatives fail or underachieve, I came up with a rather simple conclusion: “project thinking” is the root cause of these disappointments. Let me explain. Reacties (1) |
|
meer
|
|
| << Begin < Vorige 1 2 3 4 5 6 7 8 9 10 Volgende > Einde >>
| | Resultaten 1 - 11 van 166 |
Via Nova Architectura is not responsible for the content of blogs, but authors and readers are asked to adhere the following guidelines. Authors are strongly encouraged to check facts, cite sources, present
balanced views, acknowledge and correct errors. Respect copyright, fair use and financial disclosure laws. Please do not disparage organizations, or individuals. Being critical of someone's practice is acceptable, when it is done in a professional manner. Prevent usage of marketing statements. Comments should be relevant to the specific post they are attached to. Spam, flaming, personal attacks, and off-topic comments are not
permitted. Readers are requested to notify
Dit e-mail adres is beschermd door spambots, u heeft Javascript nodig om dit onderdeel te kunnen bekijken
of any violations. The editor holds the right to remove any statements that, in the editors opinion, infringe the above guideline(s). The author receives a notification of this action.
|
|
|
| |
| |
|
