• Explore More Strategy Topics

  Agile Agility Alignment Architecture Benchmark Business Cost Decision-Making Definition EA Enterprise Architecture Enterprise Archuitecture Execution Framework Good Enough Governance GTD Heuristic IEEE 1457 IT IT Governance ITIL Management Measurement Methodology Performance Planning Planninig Principle Principles Process Project Reference Architecture Research Security Simple Small Wins SOA Social Architecture Software Architecture Solution Standards Strategy Technology Thinking TOGAF Trends Zachman

• Blogroll

  • Enterprise Architecture: From Incite comes Insight…
  • Pragmatic Enterprise Architecture
  • Serge Thorn’s IT Blog
  • Smart (Enough) Systems
  • Technology Architecture & Projects
  • The Practice of Leadership
  • Todd Biske: Outside the Box
  • User-Centric Enterprise Architecture

Todd Biske wrote and interesting post on reference architecture which got me thinking… Todd asks the following two questions regarding reference architecture:

1. The first is whether or not a reference architecture should recommend specific technologies (e.g. “if you meet these conditions, you should use vendor product MagicFooBar”) or only describe the capabilities required, leaving implementations teams to choose a technology that fits (e.g. “the services tier must be exposed using XML-based interfaces”)?
2. How much guidance should a reference architecture give? Should it go so far as to place constraints on how individual classes are named, or how the file hierarchy is set up in the source code repository? Or should it remain at a level somewhere above the design of individual classes?

I agree with the view that reference architecture exists to provide guidance and for guidance to be useful it needs to be relevant to those using it. That is, reference architecture needs to be appropriate for the context in which it’s intended for use. This means that reference architecture is dependent on the stakeholders and the purpose for which it’s intended. Therefore, what constitutes reference architecture will differ from organisation to organisation. Given this Todd provides the following advice:

• A single, clear purpose for each deliverable: "….focus on delivering guidance that is singular in purpose, at least within a single deliverable… It means that you should avoid trying to answer all of the questions within a single (and likely very large) document. Rather, each deliverable should start with one simple question, and focus on answering that question clearly."
• Create a document hierarchy that moves from the general to the specific: "…The earlier documents discusses things more broadly, intending to answer the question of what collection of technologies are needed for a solution, but not necessarily guidance on the appropriate way to use that technology. For that, once the decision to use a particular technology has been made, a separate document goes into added depth, and the process continues. The reference material will eventually work its way down to development and operational guidelines (or hook up with those that may already exist)."

I thought that the above suggestions are really useful to keep in mind in our approach to reference architecture work. Any other thoughts and suggestions?

 

Technorati Tags: Reference Architecture, EA, Enterprise Architecture, Framework, Architecture

Stephanie Overby CIO.com presents her view of the Anatomy of an IT Strategic Plan as follows:

• Timing: Most IT leaders will want to start thinking about the IT strategic plan in the spring to best position themselves for the budgeting cycle. An IT organization’s first strategic plan can take anywhere from three months to a year to write.
• Time Frame: The plan should cover three to five years, with the most focus on the next 12 to 18 months unless there is a longer-term project on the table.
• Medium: Word document and/or PowerPoint presentation. Create an abbreviated version that you can turn to anytime someone has an issue or question.
• Length: 15 pages. Or less. If using PowerPoint, 25 slides. Or fewer.
• Executive Summary: The plan should begin with a summary targeted for the business audience.
• Scope: High-level goals and plans for all areas of information technology that affect the business, not just the infrastructure. A road map for IT is useful in illustrating overall strategy.
• Business Context: Lay out the specific business drivers, assumptions and plans that informed the IT strategic plan. (For example, the business is planning to acquire smaller companies so IT’s plan is to focus on integration technologies.)
• IT Principles: Short statements of purpose that will guide IT decision making and implementation.
• Metrics: Put measurements of progress in place when you create the strategic plan instead of waiting for review time to figure it all out. The goal is not precision but the ability to measure appropriate progress toward goals.
• Review: You should review the plan and revise it as necessary at least once during the fiscal year.

This is a great checklist for your IT strategy…

 

Technorati Tags: Strategy, Plan, Planning, IT Strategy, Goals, Objectives, Management

Photo by marj k

 

"You should treat decisions as an enterprise asset. You should make even the most high-volume, operational decisions as though they are enterprise decisions." - Smart (Enough) Systems

Enterprise architecture is really all about effective decision making….! At its core enterprise architecture is a tool that informs and guides decision-making…

• Planning decisions
• Investment decisions
• Solution decisions

Enterprise architecture is a tool that consists of frameworks, principles, standards, processes, reference models - anything that can help us make better decisions! What’s unique about an enterprise architecture, is that it’s built upon the a core belief that an holistic or enterprise perspective is produces better decisions than taking a silo view of the problem. A high-level holistic perspective the enables decision-making from an overall systems perspective.

 

Creating architecture, although required, produces no value. Value only comes from applying architecture to influence projects. This is best supported by a decision making approach as:

• Decisions move us from the “as-is” to the “to-be”, one step at a time.
• A focus on decisions makes enterprise architecture practical and action-oriented …rather than theoretical.
• Focuses enterprise architecture on helping to foster decision-making, rather than on the frameworks and the processes. Focusing on ends, rather than means.
• Ensures that enterprise architecture addresses stakeholder decision-making needs, as they make decisions at different levels of abstraction

 

Technorati Tags: Decisions, Architecture, Enterprise Architecture, System, Management, Practical

The March / April 2007 issue of Align Journal has an article by David Robertson, Jeanne Ross, Peter Weill Enterprise Architecture as Strategy: An Excerpt –To Execute Your Strategy First Build Your Foundation discussing enterprise architecture. The article mentions the following nine warning signs of poor IT business alignment:

1. Different parts of our company give different answers to the same customer questions.
2. Meeting a new regulatory or reporting requirement is a major effort for us, requiring a concerted push from the top and significant infrastructure investment.
3. Our business lacks agility—every new strategic initiative is like starting from scratch.
4. IT is consistently a bottleneck.
5. There are different business processes completing the same activity across the company, each with a different system.
6. Information needed to make key product and customer decisions is not available.
7. A significant part of people’s jobs is to take data from one set of systems, manipulate it, and enter it into other systems.
8. Senior management dreads discussing IT agenda items.
9. We don’t know whether our company gets good value from IT.

These nine warning signs provide a great high-level diagnostic that you can use to get a feel as to the extent that the organisations IT capabilities are aligned with the organisations business strategy and objectives. Answer the above questions, whilst reflection on your organisation. How well align is your IT capabilities with your organisations strategy?

 

Technorati Tags: Enterprise Architecture, Strategy, Alignment, Technology, Architecture, Governance

Andy Willmot writes on his view of enterprise architecture and he believes that enterprise architecture is best described as a set of principles, as follows:

• Framework driven - "….The important lesson is one of ensuring conformity to a framework, whatever that framework be. All organisations are different, and it’s up to the EA community to identify, base upon or create a fresh the most appropriate framework to use. Without a framework driving EA activity, the deliverables are often inconsistent and have little understanding beyond the EA community."
• Abstractional and Dimensional - "Our current thinking on an organisation generally leads us to perceive in two main ways. Firstly, in differing levels of abstraction. That is, the level of depth viewed of an organisation. E.g. a CTO’s level of abstraction is far different to that of a Developer.
  Secondly, by dimension. This is the vertical facet of the organisation we’re wanting to perceive. This could be information, people, function, etc. This will be very much dependent on the objectives of the EA activity."
• Vertically and horizontally interdependent - "Interdependency is key to EA. Without it EA activities become individual, siloed analysis streams that cannot relate to one another. One of the clear benefits of EA is to align these activities across an enterprise and produce architectural insight that benefits the development of the organisation."
• Purposeful - "Many EA activities today do not have clear purpose…… It’s therefore very important we remember to set clear objectives for any EA tasks and ensure we stick to them throughout."
• Measureable - "There aren’t many projects within major business today that don’t have a business case to back up the benefits of completing the project…. It’s important though to think of any EA activity as we would any other project and ensure we measure benefits to the organisation throughout."

A great list of the attributes of enterprise architecture. What attributes do you feel are missing from this list?

 

TOGAF (The Open Group Architecture Framework) defines an architecture framework as follows:

"An architecture framework is a tool which can be used for developing a broad range of different architectures. It should describe a method for designing an information system in terms of a set of building blocks, and for showing how the building blocks fit together. It should contain a set of tools and provide a common vocabulary. It should also include a list of recommended standards and compliant products that can be used to implement the building blocks."

This definition provides a TOGAF view of what an architectural framework should do….

• An architectural framework provides the necessary methodology or method by which the architecture tasks and activities are done.
• An architectural framework provides the definition of the deliverables that the architecture methodology should / must produce.

I like this definition, as many frameworks provide a description of the deliverables, but provide little guidance on how to go about producing the required deliverables. Neglecting the methodology can have sever consequences, such as, weak governance, poor IT business alignment and a lack of buy-in.

How effective is your architectural framework?

Technorati Tags: Framework, Methodology, Definition, TOGAF, Enterprise Architecture, Architecture

The IEEE 1471-2000 standard, also known as "Recommended Practice for Architectural Description of Software-Intensive Systems", describes a conceptual framework for architecture description and was published in October 2000. The scope of this recommended practice encompasses those products of system development that capture architectural information, where architectural descriptions are used for the following:

• Expression of the system and its evolution
• Communication among the system stakeholders
• Evaluation and comparison of architectures in a consistent manner
• Planning, managing, and executing the activities of system development
• Expression of the persistent characteristics and supporting principles of a system to guide acceptable change
• Verification of a system implementation’s compliance with an architectural description
• Recording contributions to the body of knowledge of software-intensive systems architecture

 

The IEEE 1471 Framework

The framework is conceptual and can be considered as a meta-framework, it does not specify the format or media for an architectural description, however it does specify certain, minimal required content of an architecture description. The key terms and concepts that are described by this framework includes:

• Architectural description (AD): A collection of products to document an architecture.
• System: A collection of components organized to accomplish a specific function or set of functions.
• System stakeholder: An individual, team, or organization (or classes thereof) with interests in, or concerns relative to, a system.
• View: A representation of a whole system from the perspective of a related set of concerns
• Viewpoint: A specification of the conventions for constructing and using a view. A pattern or template from which to develop individual views by establishing the purposes and audience for a view and the techniques for its creation and analysis.
• Concerns: are those interests which pertain to the system’s development, its operation or any other aspects that are critical or otherwise important to one or more stakeholders. Concerns include system considerations such as performance, reliability, security, distribution, and evolvability.

 

click here for larger image

 

The framework can be described as follows:

• A system has one (1) architecture
• An architecture is described by one or more architectural descriptions
• An architectural description is composed of one or more of stakeholders, concerns, viewpoints, views, and models
• A stakeholder has one or more concerns
• A concern has one or more stakeholders
• A viewpoint covers one or more concerns and stakeholders
• A view conforms to one (1) viewpoint
• A viewpoint defines the method and patterns of a model
• A view has one or more models and a model is part of one or more views
• A viewpoint library is composed of viewpoints (reference architecture).

 

This conceptual framework provides an excellent foundation on which to build robust architectural descriptions. What I like about this framework is that it’s stakeholder and purpose focused, two factors that often become lost in an intensive architectural effort. All architecture must be stakeholder focused and deliver architectures that stakeholders can understand and which stakeholders can use for decision making.

• How well are you architectures described?
• Are the various stakeholder needs described and addressed with appropriate viewpoints?
• Are they understood, that is, have they resulted in the right technology decisions?

 

< Technorati Tags: IEEE, 1471, Standards, Views, Viewpoints, Architecture, Enterprise Architecture, EA, Framework, Methodology

According to PRNewswire, "Information Security Management will be the most important initiative affecting IT strategy, investment and implementation in business organizations over the next 12-18 months, according to the American Institute of Certified Public Accountants’ 19th Annual Top Technology Initiatives survey."

The AICPA poll was conducted in late 2007 with ISACA, the Institute of Internal Auditors (IIA) and the Information Technology Alliance (ITA). Respondents identified the top 10 most important technology initiatives for 2008 as follows:

1. Information Security Management
2. IT Governance
3. Business Continuity Management and Disaster Recovery Planning
4. Privacy Management
5. Business Process Improvement, Workflow, and Process Exceptions Alerts
6. Identity and Access Management
7. Conforming to Assurance and Compliance Standards
8. Business Intelligence
9. Mobile and Remote Computing
10. Document, Forms, Content and Knowledge Management

"Recent studies show that investors are willing to pay a premium of up to 20 percent more for shares of enterprises with reputations for good ITgovernance practices; properly governed IT is critical to an organization’s success," said Lynn Lawton, International President of ISACA.

Are you looking into these information technology initiatives?

Technorati Tags: Research, Governance,Security, Survey, DR, BI, Business Intelligence

I like to describe architecture as the "art and science of seeing the big picture, it’s components and their inter-relationships". In the book "The art of systems architecting" the authors describe architecture as both and art and a science.

 

 

• Normative - solution-based: This architecture method is founded on a strong science-based approach, prescribing architecture as is should be, as it’s described in building codes, handbooks and civil codes. This method for the development of architecture create well defined patristic architecture.
• Rational - method-based: This architecture method is founded on a strong mathematical and scientific principles to arrive at a solution, strongly based on systems analysts and engineering.
• Participative - stakeholder-based: This architecture method is founded on understanding he complexities that exists when working with multiple stakeholders. The objective of the approach is to reach consensus. Concurrent engineering and brainstorming a both tools used in this method, typically this is approach us characterised as "architecture by committee".
• Heuristic - lessons-learned: This architecture method is founded on common sense, driven by what is sensible in the given context. This contextual sense results from the collective experience of those involved in the architecture. Heuristics or lessons learned from experience, for example to simplify, are used as guides in the development of the architecture.

 

Considering the holistic nature of enterprise architecture and the complexities involved, the integration of these four classic architectural methods into how we develop enterprise architecture make for a robust outcome. The enterprise architecture methodology used needs to integrate these four paradigms.

• Is your architecture methodology solution-based?
• Is your architecture methodology method-based?
• Is your architecture methodology heuristic-based?
• Is your architecture methodology stakeholder-based?

 

Technorati Tags: Methodology, Framework, EA, Enterprise Architecture, Architecture,Stakeholder, Art, Science, Method, Management,Technology

• Search for:

• Welcome

  Welcome to Architecture and Change. You can subscribe to my blog using RSS or you can subscribe by e-mail

• Contact

  
  
  

• Busy Reading...

• Interesting Blog Stats

• Show of Support