lunes, 25 de agosto de 2014
Lean IT, una declaración de objetivos
http://www.aunclicdelastic.com/lean-it-una-declaracion-de-objetivos/
Los principios de Lean IT se resumen en las “5 S”, que se corresponden con los siguientes términos japoneses:
- seiri (clasificar)
- seiton (ordenar)
- seiso (limpiar)
- seiketsu (simplificar, estandarizar)
- shitsuke (disciplinar)
EA Tools
-
http://www.computerwoche.de/a/18-ea-tools-im-vergleich,3066120
-
ABACUS de previsiones de evolución,
-
ADOit del BOC AG,
-
ARIS de Software AG,
-
BiZZdesign EA Tool Suite desde BiZZdesign,
-
Casewise Corporate Modeler Suite,
-
Enterprise Architect de Sparx Systems Ltd el,
-
Imagine VIP de Future Systems Tech,
-
iteraplan del iteratec GmbH,
-
Layer8 del Layer8-Solutions GbR,
-
leanIX del LeanIX GmbH,
-
MEGA MEGA International,
-
planningIT por Software AG,
-
PowerDesigner de Sybase o SAP AG,
-
process4.biz del desarrollo y distribución de software process4.biz GmbH,
-
QPR Enterprise Architect de QPR Software,
-
Rational System Architect de IBM,
-
Repositorio SAMU Atoll Technologies Ltd y
-
Txture del QELaB Business Services GmbH.
domingo, 24 de agosto de 2014
Enterprise Architecture Artifacts
We enterprise architects produce artifacts. Artifacts are what the architecture is made of. Some goofballs think its all data, and the physical presentation is secondary. I think if two architects cannot read each other's artifacts there is a problem. Just call me "old school".
In the image is an example DoD OV-2, a typical artifact.
In my experience there are four kinds of artifacts in EA, and in engineering drafting. These are 1) Lists; 2) Matrices; 3) Drawings and 4 Documents. Just four.
Lists contain the basic building blocks of your architecture. An architecture is a set of elements and the relationships between them. The lists identify the elements. They can have attributes, or columns. Example lists are 1) technical drivers; 2) applicable policies and laws; 3) servers; 4) office locations, 5) major business functions.
Matrices have the elements of one list on the x axis, and another set of elements of (usually) a different list on the Y axis. Then you note the relationships between the elements. In one notable case each axis has systems on it, and the matrix shows interfaces.
Drawings depict relationships. There are many standards for how things might be drawn, such as IDEF or BPMN or ERDs. If you are drawing stuff with no standard, you may be an armature. There are some cases where the expert makes up a new type of drawing though.
A document will use textual narrative to tie these other artifacts together.
Here are some tips:
- Do not try to put too many kinds of things on a drawing. Two or three is enough. Sometimes its only one kind of thing and the connections between them. This is one of the biggest errors in producing architecture artifacts.
- You can use larger sheets. Honest. Do not stick to A sized 8.5 x 11 paper.
- Engineering control blocks and CM info on the sheet is a nice touch. Use real discipline in controlling the modifications of your artifacts.
- DODAF is full of example useful artifacts. Martin wrote a book on diagramming techniques. Use existing forms before making up new ones.
- Be very clear of your terms and constructs, know exactly what they mean. Have some discipline with that.
- Put only the useful kinds of things in your architecture, not too many kinds of things. Keep it small, or as small as it takes to cover your purpose.
- An architecture will consist of several kinds of lists, matrices, drawings and maybe a document or two. One drawing is not much of an architecture. Different artifacts tell different aspects of the story.
viernes, 22 de agosto de 2014
EA Framework vs Methodology
A framework provides a structure to organize things. So the F in TOGAF means that there is a structure. One of the elements of this structure is a methodology. The methodology is called ADM (Architecture Development Method). A method is a way of doing things. Usually consisting of phases and steps. A methodology contains one or more methods. However in real life you have to be very careful. A lot of architects and other counterparts, are using terms like framework, method, methodology, approach and process in their own specific way. So I've made a practice to ask what it is they mean with this terms. Asking this early in the conversation usually avoids a lot of confusion and misunderstanding