domingo, 31 de agosto de 2014
sábado, 30 de agosto de 2014
jueves, 28 de agosto de 2014
EABok
http://www2.mitre.org/public/eabok/
What is Enterprise Architecture?
Enterprise Architecture analyzes areas of common activity within or between organizations, where information and other resources are exchanged to guide future states from an integrated viewpoint of strategy, business and technology.
What is the Enterprise Architecture
Body of Knowledge?
The Enterprise Architecture Body of Knowledge (EABOK®) is a living, evolving reference of ready-to-use knowledge that describes the essence of enterprise architecture. To increase understanding, the components of this reference are organized, contextually linked, and visualized, and are intended to serve the EA community from novice to expert.
Learn more
- See more at: http://www2.mitre.org/public/eabok/#sthash.KQ7Zs3mJ.dpuf
miércoles, 27 de agosto de 2014
IT Strategy and Governance
http://www.pwc.com/ca/en/technology-consulting/technology-advisory/it-strategy-governance.jhtml
Developing business-focused plans and governance structures
PricewaterhouseCoopers can help you develop a technology strategy aligned to your business objectives. Our team of seasoned advisors have helped clients in many industries using their experience in IT architecture, IT management, IT governance, compliance, risk, IT sourcing and service delivery.
If your business needs a strategy or governance structure to improve the effectiveness of your IT operations, our team can provide a tailor-made solution to get your IT function on track.
How PwC can help
Leveraging PricewaterhouseCoopers’ leading methodology and frameworks including our TRANSFORM™ IT framework, we help you develop:
- IT Strategic Plan: We identify gaps between your IT function (strategy, structure, people, process, technology) and your current and future anticipated organizational direction. We then collaboratively work with you to design a “blueprint” of your future operating model as well as a roadmap outlining the short, medium and long term initiatives required to get you there.
- IT Governance Program: We help you design and implement the organizational, reporting and risk management changes necessary to execute your strategy. Typical drivers include a desire to better align IT with the business, a desire to reduce cost and complexity, a need to better manage risk and compliance or a need to remediate service quality issues.
martes, 26 de agosto de 2014
The Missing Role of the Segment Architect
A segment is just a sub-division or subset of the full enterprise
Have you ever come across anyone with the title – “Segment Architect”? No? Well neither have I. And yet the role is one that crops up in several parts of the TOGAF® documentation. So what is this missing role of the segment architect?
I’ll start by listing the places in TOGAF where you will find mention of this elusive role:
- In the Architecture Skills Framework (Chapter 52) TOGAF describes three categories of architect – Enterprise Architect, Solution Architect, and Segment Architect.
- In Applying the ADM across the Architecture Landscape (Chapter 20) and the Architecture Repository (Chapter 41), TOGAF divides the architecture landscape into three levels of granularity or types of organizing framework:
- Strategic Architectures, which show a long-term summary view of the entire enterprise, supporting operational and change activity and allowing direction setting at an executive level.
- Segment Architecture, which provides more detailed operating models for areas within an enterprise, supporting operations and change, through direction setting and architecture roadmaps at a program or portfolio level.
- Capability Architectures, which show in more detail how the enterprise can support a particular capability by developing architecture roadmaps to realize capability increments.
[Note: the idea of partitioning the architecture according to these three levels is discussed further in Architecture Partitioning (Chapter 40)]
- This idea of partitioning the architecture into three levels of granularity is also discussed in the Introduction to the ADM (Chapter 5). In this chapter TOGAF talks about how architecture artifacts need to be integrated across these levels.
The key point here is that segment architecture is simply “a detailed, formal description of areas within an enterprise, used at the program or portfolio level to organize and align change activity” (link).
In other words, a segment is just a sub-division or subset of the full enterprise. Any sub-division or subset, however you choose to make that subdivision.
Some organizations have segments that correspond to the organization structure. For example, within a large international bank there might be a Retail Bank Segment and a Corporate Bank Segment. But the architect responsible for these areas would probably be called “Retail Bank Architect”, or possibly be given a more generic title like “Business Unit Architect”.
Other organizations have architects responsible for particular sub-domains. For example, there might be an architect responsible for Payments, Customer Relationship Management, or Fraud. The job title for these architects might include the domain name, such as Product Architect, or it might reflect a functional area within a business, such as Sales and Support Architect. TOGAF describes four high-level domains – business, data, application and technology – and these are often used in the job titles for architects focusing on those subjects.
TOGAF is not actually describing a particular role, but more of a type of architecture role. If we go back to the summary of the three types of Enterprise, Segment and Solution architect in Chapter 52, it becomes easier to see what TOGAF means by segment architecture.
All types of architectural role have responsibility for the planning, defining, documenting and managing some aspect of the architecture – it’s just at different levels of detail, scope and domain subject matter.
- The Enterprise Architect looks after the architecture at a landscape and technical reference model level. In other words – it’s a broad view across the whole of the enterprise. It’s a role that provides holistic overview and coordinates all views and viewpoints. Often the Enterprise Architect might also lead a team that consists of Segment and Solution Architects. Typically the enterprise architect relies on the segment and solution architects to provide detail, so that the enterprise architect can focus on how everything works together in a systemic, collaborative, synergistic way.
- The Segment Architect focuses on a specific aspect of the business or organization. They look up to the enterprise architect to provide the overall context of the work they do. But they also need to look sideways to other segment architects – to make sure that their segment fits with the architectures in those areas.
- The Solution Architect operates at a system or subsystem level – which often means that they are directly engaged in projects and architecture delivery. The solution architect is the one that knows the detailed information about systems, products, and technologies; for example, they might be the expert on data warehouse architectures. A solution architect looks to the segment and enterprise architecture roles to provide the contexts in which a detailed architecture fits.
The role of Segment Architect isn’t missing; it is more veiled or obscured. It is not obvious because architects are not typically given the title of Segment Architect. But when we search further we find that the distinction between “enterprise”, “segment” and “solution” helps to explain the key difference between the three types of architecture role.
Look within your enterprise and you will find plenty of examples that fit the Segment Architect type of architecture role.
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
jueves, 21 de agosto de 2014
miércoles, 20 de agosto de 2014
lunes, 18 de agosto de 2014
BTM2 AND ASAP – SAP’S PERFECT MATCH
BTM2 AND ASAP – SAP’S PERFECT MATCH
http://www.bta-online.com/blog/2013/btm2-and-asap-saps-perfect-match/
