• 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

 

Mike Walker wrote and interesting post on a discussion he had on “Making Sense of Architecture Standards" which resulted in the following image:

 

 

• Taxonomy and Ontology: Such as IEEE 1471, “. . .an architecture is a conception of a system. There may be many conceptions of a system… What this provides to the enterprise architect, solutions architect or domain architect is a way to have a constant set of terms for describing what it is they are building. This should be at the core to your architecture activities.”
• Information Model and Decision Support: Decision support help us to "..focus more on … What are the right questions  … How do I organize those questions … What do those answers mean … Meaning what is the process in which I get the information, consume it, process it and ultimately make it actionable."
• Process Framework: "… when talking about decision support, there is a need for a process to wrap how we make our decisions…. Having this higher level process framework is essential to architects. There are a series of benefits for the organization … Constancy in how solutions are created … The right people are selected for the right job … Proper metrics can be obtained to gauge health of the EA process … Predictability of results which lends to being able to apply some level of risk management to decisions"
• Actors: These are people with the appropriate skills and competencies.
• Manage: The ability to effectively execute strategy and tactics "…This aspect covers PMO based processes, service management and IT Governance aspects. In the service management area specifically we are seeing closer alignment with EA. The latest version of ITIL has alignment with EA practices."

This is a great overview of the enterprise architecture standards and how they relate and interact.

 

Technorati Tags: EA, Enterprise Architecture, Framework, Standards, ITIL, TOGAF, IAF, Zachman, IEEE 1457, PMO, Process

An article from Cio.com title "The Productivity Gap Between Mid-Market and Large IT Shops" really struck a cord with me. The IT service management consulting at Enterprise Management Associates (EMA) performed an analysis of recent data trends and found that:

"IT departments in Fortune 1000 enterprises actually are more productive and effective service providers than mid-market counterparts—and it has nothing to do with the amount of staffers or money spent."

Having worked in both large and mid-market IT shops, my experience supports their findings, consider the following results from their research:

• Ninety percent of mid-market IT organizations use manual processes.
• Seven out of 10 calls for IT support are a direct result of incorrect operating procedures, meaning self-inflicted by the IT staff.
• Eight out of 10 IT system outages are caused by a failed change—meaning, an IT staffer "didn’t take the time to consider the ramifications of making a change to the infrastructure,"
• As much as 80 percent of the actual IT department is replicated by "shadow IT" workers in the business because IT is too busy to service their customers effectively.
• Research from EMA and The Standish Group show that approximately 70 percent of mid-market IT projects fail.
• Larger companies of the Fortune 1000 support almost three times—2.9 times, to be precise—as many users per IT staff member than mid-market companies….. The Fortune 1000 user-to-IT-worker ratio is 512 users for every one IT worker; in the mid-market, the ratio is 175-to-1…..this makes "mid-market IT organizations only about one-third as effective as their larger Fortune 1000 cousins.

The reason for the different in large and mid-market organisations is not about the money spent of IT and it’s not about the number of staff. The primary difference is in the productivity of the IT organisation. The reason for the low levels of productivity in mid-market organisations are due to:

1. Lack of specialisation: The research found that mid-market organisations have "more generalist approach with a shared team and few if any specialists…. These teams work harder and have less time to dedicate to any particular technology or specialization".
2. Poor IT processes: "IT is too busy to adopt huge [process-oriented] frameworks like ITIL, Six Sigma, CobiT or formal IT project management," Marquis writes. "But the reason they are so busy is precisely because they have no formal processes…. average IT organization is its own worst customer and responsible for most of the outages to which it finds itself reacting," he writes. "In fact, most of the work going on in the average IT organization is not productive work at all, but rather is re-work."

This research provides some interesting insight into mid-market IT organisations. If you’re working in a mid-market IT organisation investing in robust IT processes and specialisation can significantly increase the productivity of your IT shop.

 

Technorati Tags: Specialisation, Strategy, Research, Process, ITIL, COBIT

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