Category: TOGAF

The Open Group Architecture Framework, or TOGAF, is intended to provide a structured approach for organizations seeking to organize and govern their implementation of technology, particularly software technology. In that sense, its objective is to employ an encompassing conceptual framework to try to ensure that software development projects meet business objectives, that they are systematic and that their results are repeatable.

TOGAF was created and is maintained by The Open Group, an independent industry association. It builds on an earlier framework known as TAFIM, or Technical Architecture Framework for Information Management, originally devised by the U.S. Defense Dept. In early 2009, The Open Group released TOGAF version 9. The Open Group and others commonly lead TOGAF certification and educational programs today. Typically, enterprise architects lead use of TOGAF within organizations.

Like its TAFIM forerunner and many other frameworks, TOGAF owes a debt to the work of John Zachman, who created the Zachman Framework, a related schema to facilitate discussion between different software development stakeholders and improve software project and program outcomes. This and similar frameworks seek to effectively organize requirements gathering,to make sure what is built is what is needed. Zachman’s landmark work in the 1980’s while at IBM, brought context to the development process without endorsing a specific software language or methodology. Like TOGAF today, it clarified terms and roles, focusing on the ”What, How, When, Who, Where and Why” of technology implementation.

The basic TOGAF 9 document contains descriptions of an architecture development method and related techniques, an architecture content framework, an enterprise continuum, TOGAF reference models and a capability framework. Version 9 creates a model for extensibility, among other enhancements.

TOGAF need not be used ”whole hog.” While the basic TOGAF document runs to many pages, a pocket-book version is available too. Experienced professionals can focus on the aspects of TOGAF that work best for their organization as they pursue business benefits derived from software innovation.

TOGAF has enjoyed considerable adoption in organizations of diverse character. Its use is seen as a potential systematization of efforts – in the wake of high-profile failures – by governments, businesses and others to apply structured enterprise architecture principles to the still somewhat ”black arts” of software development and IT operations. TOGAF can be used with – or without – service-oriented architecture (SOA), UML and various frameworks, methodologies and tools of modern software development.

In the development of a house, building or any object we can always identify the following main steps:
• A discovery process to identify the needs and requirements in the context of a certain situation;
• A design process which leads to a design of the object in the form of drawings and/or models;
• A transformation process to plan the realisation of the object in its environment;
• A construction process that regards the realisation of the actual object based on the design and realisation plan.

The principles, guidelines and rules identified in the discovery phase are used in both the design, transformation and construction process. As such, the architecture impacts all processes.

The architecture constraints the freedom of the designer and constructor of the object and guides them towards a structure that complies with the business vision and concepts of the architecture. The architecture serves as a prescription for the
design, transformation and construction of the object. As a result the object will be recognised as being ‘designed and constructed under architecture’. The object will inherit the added value of the architecture and will support the (cultural) values, goals and objectives of the organisation. The described role of architecture originates from the building industry. In prescribing the structure, function and style of a building the architecture defines principles, guidelines and rules for:

• The type of components of which the building may be composed; • How these components must fit together; • What assemblies of the components are allowed;

• What functions (usage, living, and working) do the components and component assemblies support;

• And how the style represents the values of the owner. The prescription concerns the overall architecture as well as the design models and the actual construction of the building. IFEAD uses the same approach by defining the architectural steps for architecting business / organisations and IT systems. In prescribing the structure of an organisation and its related business or an IT system the architecture defines principles, guidelines and rules for:

• The type of components of which the business or system may be composed;

• How these components must fit together;

• How the components communicate and co-operate;

• What assemblies of the components are allowed;

• What functions (communication, control, security, and information) the components and component assemblies support;

• And how the style expresses the (cultural) values of the stakeholders of that organisation.

Paramount to the enterprise architecture is the identification of the sponsor, his/her mission, vision and strategy and the governance framework to define all roles, responsibilities and relationships involved in the anticipated transition.
As the purpose of architecture is: “INSIGHT, TO DECIDE, FOR ALL STAKEHOLDERS”, enterprise architects work very closely with the enterprise sponsor and key stakeholders, internal and external to the enterprise. The architect understands the enterprise mission, vision and strategy and the sponsor’s ideas about the approach. The architect articulates the existing enterprise infrastructure value-chain: market, business, systems and technology. Architects present and discuss the technology, systems, business and market options to fulfill the enterprise mission. Insight is improved by using the ‘solution architecture’ which is, relative to the decisions ahead, a specific blend of technology, systems, business and market options. Together with the sponsor and the main stakeholders, they make informed choices about the options. For large transitions, architectural decisions are supported by proofs-of-concept and/or business pilots.
Enterprise architects use various methods and tools to capture the structure and dynamics of an enterprise. In doing so, they produce taxonomies, diagrams, documents and models, together called artifacts. These artifacts describe the
logical organization of business functions, business capabilities, business processes, people, information resources, business systems, software applications, computing capabilities, information exchange and communications
infrastructure within the enterprise. A collection of these artifacts, sufficiently complete to describe the enterprise in useful ways, is considered by EA practitioners an ‘enterprise’ level architectural description, or enterprise architecture, for short. The UK National Computing Centre EA best practice guidance states Normally an EA takes the form of a comprehensive set of cohesive models that describe the structure and functions of an enterprise. and continues
The individual models in an EA are arranged in a logical manner that provides an ever-increasing level of detail about the enterprise: its objectives and goals; its processes and organization; its systems and data; the technology used and any other relevant spheres of interest. This is the definition of enterprise architecture implicit in several EA frameworks including the popular TOGAF architectural framework. An enterprise architecture framework bundles tools, techniques, artifact descriptions, process models, reference models and guidance used by architects in the production of enterprise-specific architectural description. Several enterprise architecture frameworks break down the practice of enterprise architecture into a number of practice areas or domains.

It is tempting to say that if the head of an organization doesn’t see the need for an EA model, then it is probably a simple enough organization not to need one. However, the truth is that most enterprises started out small and simple, where one person could genuinely understand the whole thing, but grew to the point where no single person could describe the whole. The same can be said of the corresponding IT systems that support the enterprise. The problem is that the people who
run these enterprises are loathe to admit (or often don’t even realise) that the level of complexity has grown beyond their ability to comprehend. This culture of denial is behind many of the management disasters of the information age – assumptions based on poor understanding of the key dependencies, weaknesses and bottlenecks in an organization have resulted in poor decision making. In the last few years, there has been a spate of corporate mergers of very large companies. The merged organizations each had their own cultures, processes, terminology and technology. Understanding how best to rationalise these organizations is only possible using models at an enterprise level – hence the recent upsurge in interest in EA. The benefits of EA are not always easy to measure – anyone with experience of change projects in large organizations can see that an EA approach is valuable, but it is hard to put a monetary figure on the benefits. Even just concentrating on tangible projects such as IT delivery, it is hard to put a figure on the benefits of EA. There are many opinions on why large IT projects tend to fail so spectacularly, but running through all of them are some key threads:

• Gaps in understanding – the business community are unable to elucidate their requirements to the technology providers, and the technology providers are unable to describe the impact of technology changes in such a way that the business community can understand the risk.
• Weakness of verbal requirements – written specifications are open to interpretation and contribute to gaps in understanding
• Lack of project cohesion – it is very difficult to coordinate a large development team to work towards a singular goal when their allotted tasks are specialised and isolated

It is clear that a well executed EA approach helps to overcome all these problems, but this still a “good feeling” rather than anything that can be measured. The only way to measure the benefits is to compare two almost identical projects, one which used an EA approach and one which did not.

Domain Logic Patterns: Transaction Script , Domain Model , Table Module, Service Layer .

Data Source Architectural Patterns: Table Data Gateway , Row Data Gateway, Active Record , Data Mapper .

Object-Relational Behavioral Patterns: Unit of Work , Identity Map , Lazy Load

Object-Relational Structural Patterns: Identity Field , Foreign Key Mapping ,Association Table Mapping , Dependent Mapping , Embedded Value ,Serialized LOB , Single Table Inheritance , Class Table Inheritance ,Concrete Table Inheritance , Inheritance Mappers .

Object-Relational Metadata Mapping Patterns: Metadata Mapping , Query Object, Repository .

Web Presentation Patterns: Model View Controller , Page Controller , Front Controller , Template View , Transform View , Two-Step View ,Application Controller .

Distribution Patterns: Remote Facade , Data Transfer Object

Offline Concurrency Patterns: Optimistic Offline Lock , Pessimistic Offline Lock, Coarse Grained Lock , Implicit Lock .

Session State Patterns: Client Session State , Server Session State ,Database Session State .

Base Patterns: Gateway , Mapper , Layer Supertype , Separated Interface , Registry , Value Object , Money , Special Case ,Plugin , Service Stub , Record Set

Enterprise storage is a broad category that includes products and services designed to assist large organizations with saving and retrieving digital information. Unlike consumer or small business storage devices, enterprise storage can handle large volumes of data and large numbers of users. It usually involves centralized storage repositories, such as storage area networks (SANs) or network-attached storage (NAS) devices.

Enterprise storage can be broken down into several categories. Primary storage houses the data that end users are actively accessing. Backup storage contains copies of the information in primary storage for use in disaster recovery situations or in other circumstances where a secondary copy is necessary. Backup storage is closely related to archive storage, which is where enterprises keep outdated information that needs to be saved for compliance or other purposes.

Whether on-premise or cloud deployment

Organizations can choose to purchase and deploy on-premises enterprise storage systems, or they can choose to store their data with an external cloud computing service. The advantage of on-premises enterprise storage is that the organization retains complete control of the hardware and data, satisfying some security and compliance concerns. On the other hand, cloud-bases enterprise storage simplifies storage management and may lower costs in some cases. Some companies take a hybrid approach and use a combination of both on-premise and cloud-based storage.

One of the key benefits of enterprise storage solutions is that they enable file sharing and collaboration among workers. Many offer security features, such as user-based permissions, that aren’t commonly found in consumer storage solutions. Enterprise storage also offers better performance, reliability, availability and scalability than other types of storage solutions.

Storage Networking and Management

Enterprise storage devices utilize similar technology as consumer and small business storage solutions. However, enterprise data storage generally offers higher reliability, availability and scalability. As a result, enterprise storage generally costs more than consumer or small business storage. It also usually requires more time and expertise to set up, while many consumer storage vendors takes a plug-and-play approach, and enterprise storage networks are typically run by specialized personnel or administrators.

When we think of working on Enterprise Architecture, we start with few common mistakes which if can be avoided then the journey ahead is relatively less complex.

1. We think it’s a technical problem. We think it is solvable by API, Web services, XML, enterprise resource planning or some other technology that changes every six months. Fat chance.

2. We haven’t truly tackled the problem. Over the years, we’ve defined the enterprise integration problem scope as order fulfillment then supply chain management, more recently customer relationship management and product lifecycle management. But really those are parts of the problem.

If you want to integrate the enterprise, then the scope of your problem is the whole enterprise. Arguably that’s a big, complex problem. But so is building a skyscraper, a planned community and the Panama canal. Your enterprise is everything from human resource management to marketing, manufacturing, distribution and finance and everything in between. That’s the scope of the enterprise integration problem.

3. We haven’t had a well-developed methodology for solving this problem. Enterprise architecture provides this methodology. Enterprise architecture provides a framework of principles, policies, models and standards.

The models break the enterprise down into distinct, manageable parts, one of the basics of problem solving. I’m not talking about the Holy Grail of reusable software components. I’m talking about the big picture. What are the business processes and data of the enterprise? And how do they fit together to create an integrated whole?

This is a thoughtful exercise, one best done by senior management with broad knowledge of the enterprise. Our enterprise “parts” are not arbitrary. If we do a good job, we will make it crystal clear what our enterprise “parts” are, where the integration points are, which ones should be common or standardized across our enterprise and which ones can be unique for each business unit.

For example, you may want common financial and HR business processes, but different manufacturing processes for each business unit. There is some brain-busting work that has to done in deciding what is in and out of each business process and how common you want that part of your enterprise to be. And it is critical to get the breakpoints between the parts right.

The principles, policies and standards of the enterprise architecture framework provide for some rigor and rules in how the individual parts are designed and built so that they will fit together in the end. All you third-party software developers out there, you’ll need to help us out by coming up with some standard definitions of your modules (parts) so you can become interchangeable. (Yes, we know this isn’t in your best interest). Don’t forget that the principles, policies and standards have to be developed not only for technology but also for data and business processes.

So…

First, let’s tackle the real integration problem: the enterprise. Second, let’s stop hoping that technology is going to solve the enterprise integration problem. Third, let’s use enterprise architecture to thoughtfully break the enterprise down into distinct, manageable parts and provide some principles, policies, models and standards so that we can turn people loose within an architected framework to integrate the enterprise.

“Avoiding the pitfalls in the first place is much easier than climbing out of a hole you’ve inadvertently tumbled into,” said Scott Bittler, research vice president at Gartner. “Applying the ways to avoid these pitfalls results in achieving EA benefits faster and reduced risk of programme failure. It will also improve the credibility of IT among business leaders.”

The ten EA pitfalls include:

1. The Wrong Lead Architect: Gartner identified the single biggest EA problem as a chief architect who is an ineffective leader. He or she may understand EA well but has ineffective leadership skills that even a good organisational structure and staffing levels cannot overcome. Gartner recommends that such a lead architect be replaced by someone with strong ‘soft’ skills such as enthusiasm, communication and passion, as well as being well respected and strategically minded.

2. Insufficient Stakeholder Understanding and Support: This happens when employees outside the EA team don’t participate in the EA programme, EA content is not used in projects and management questions its value. Gartner’s solution is to make EA education and communication a top priority to secure executive-team sponsorship. “The key is to ‘sell’ first and architect later,” said Mr Bittler.

3. Not Engaging the Business People: When IT and business goals are not aligned, resultant problems include non-technical people trying to make technical decisions while enterprise architects become too reactionary and tactical in response to projects. To overcome this, Gartner recommends that enterprise architects get involved in the development of the business context and engage jointly with other employees in the business architecture.

4. Doing Only Technical Domain-Level Architecture: This dated EA approach is still in use in some organisations and is even narrower in scope than technical architecture. Holistic EA best-practice is much broader as it includes business, information and solutions architecture.

5. Doing Current-State EA First: Successful EA provides prescriptive guidance but current-state EA does not, so it delays delivery of EA value and hinders the creation of good future-state EA. “The temptation is often to do the easy – current-state – EA first,” said Mr Bittler. “Instead, establish the business context and then focus first on future-state EA.”

6. The EA Group Does Most of the Architecting: This is a pitfall because the EA content is typically off the mark as it was not informed by those on the business side. There is also consequently no buy-in for the EA. The primary job of architects is to lead the EA process rather than impose EA content on the organisation. They should form virtual teams to create content and seek consensus on the content.

7. Not Measuring and Not Communicating the Impact: The value of EA is often indirect, so it may not be obvious to everyone in the organisation. This then exposes the EA programme to risk of failure. Gartner recommends that enterprise architects create a slide to demonstrate each success story of EA applied to a project. They should include measurement and documentation of EA in the programme plan.

8. Architecting the ‘Boxes’ Only: Enabling better business agility and integration is key but architecting standards for the ‘boxes’ (business units) in process, information, technical and solutions models doesn’t address this. Integration and interoperability standards are high EA priorities and must account for more than just technical architecture. Architects should focus more on the links between the boxes.

9. Not Establishing Effective EA Governance Early: Enterprisearchitects must resist the temptation to wait for more architecture content before setting governance processes and instead develop content and governance in parallel.

10. Not Spending Enough Time on Communications: Key messages about EA are not intuitively obvious, so enterprise architects must work to educate the business. It is critical that organisations develop and execute an EA communications plan with messages tailored to each audience.

“The key for enterprise architects is to create not the perfect or most elegant architecture for the moment, but the most adaptable architecture for the future,” said Mr Bittler. “EA is a challenging discipline and careful attention to the basics can mean the difference between failure and success.”

Compared to many industry practices, EA is considerably an emerging discipline which still take time to mature, in last two decades, there are many challenges literally EA programs face, organizations need to analyze them and understand the underlying causes

1. Fitness for purpose. Consistent definition and understanding of EA as a discipline adds to challenges. Most organizations stand up EA to “fix” an organization without giving it any purpose. Often, consultants/contractors try to sell the Titanic of EA before they can prove a sailboat which can float. This is what often results in annoying the clients and has lead to the view of EA being shelf-ware.
2. Senior executives buy-in and continuous focus and support upon the EA program. This is like a chicken and egg issue. Executives would have continuous support if EA can deliver value,  but EA need continuous executive supports to show value. EA is in a domain where you don’t find too many quick wins. In addition, a successful EA would often lead to corporate culture change. Without strong senior executives’ commitments, corporate culture change just won’t happen. Many feel that time and money is being wasted till they start seeing in the results.
3. Understand Stewardship and Ownership differences. Too often an EA attempts to take ownership of a business process and ends up getting blamed. An EA is a Steward to practice strategic EA Leadership & Operational Stewardship –> alignment of execution with Strategy is extremely critical for EA success.
4. EA Maturity: EA engagement model and governance. This gears toward corporate processes, politics and people issues. Enterprise Architecture is simply a heavy burden to a lot of people and projects if EA engagement and governance model is not efficient and effective. Somehow, fragmented EA engagement model and governance process is very common at work place. It seems taking forever to streamline. In other words, Governance and Compliance inward is extremely important.
5. Organizational Maturity. A mature organization is base to start a successful EA program; on the other side, an effective EA program improves organizational maturity. Too many organizations try to institute an EA program when the organization is not prepared to do so. Often, leadership hears or gets the pitch that EA will save the day and they start a program, without supporting the program, thinking that “doing” EA will fix everything. EA requires wide preparation and active participation.
6. Business/Architecture Alignment –> This has to be earned by EA Team and should not be considered a blank check or an entitlement, as this would require relationship management and transparency in delivery to match the business priorities. PMO and Architecture team are critical for earning and establishing the trust.
7. Move from Vendor/Group/Institute-centric EA to Customer-centric EA. Advance from just being DNAor “enterprise genotype” (a full nomenclature of enterprise artifacts) to provide a formal link with “enterprise phenotype” (a set of observable characteristics such as performance) and business ecosystem.
8. Constant jockeying with “tactical project savings” vs. “sustainable strategic advantage” argument…(classic misalignment of project team goals with architecture team goals!).  Starting too big,  that the EA initiative doesn’t get success as originally intended. It is extremely important to start small and produce results to gain trust. Planning and prioritizing some quick wins to demonstrate what change a complete EA can bring to a enterprise. Though it is very difficult since it can backfire at times. Still, EA needs to demonstrate directly quantifiable ($$$) value – contribution to company’s bottom line or direct savings as a result
9. Mature EA Team: The EA team which don’t just believe in Framework and Technology but also has the capability to carry the business with them and got a thick skin to sail through the politics and policies Staff. Also, it is not about the “chief architect,” it is about the team of architects/support staff, a mature EA team. 
10. EA Skills/Talent: Architecture is more of an art than a science and requires more skills than certifications. Enterprise Architect requires broad knowledge from many aspects of, business domains knowledge, technologies project management experience, and organizational skills. There are many channels to mature as an Enterprise Architect. Enterprise Architects with different maturing paths may see the same organization with very different challenges.

1. Lack Of Sponsorship.

Your architects need three tools to do a good job: access, leverage and goodies.

Access means the ability to interact with the appropriate stakeholders, often at the C-level.

Leverage includes the right place in the reporting chain, involvement in governance, ability to influence the technology budget, and authority to stop inappropriate technology implementations. Sometimes even the seemingly small change of a title from technical architect to chief enterprise architect can make a significant difference.

Goodies include the ability to give out new technologies for testing, “lend” technology experts to struggling projects, and get access to exclusive information that can be traded for favors.

Well-sponsored architects will be able to build trust by consistently delivering meaningful results. Lack of sponsorship will destine even the best architects to fail.

2. Hiring Or Promoting The Wrong Person.

The skills that earn someone the EA position don’t necessarily make the person a strong EA. Often the most technical people get promoted when they lack other important skills. These include interest in the business, the ability to translate technology into simple business outcomes, and the ability to listen, communicate, present and market infectious enthusiasm for new technologies.

3. Building An Ivory Tower.

Some EA programs hire a bunch of brilliant architects who retreat for a long time and return with sophisticated frameworks. They then present them to key members of the leadership and the organization, most of whom will have no clue what the architects are talking about, so their complex reference architectures will be ignored.

Ivory towers tend to increase the complexity and upset the stakeholders. The new CIO will gain immediate recognition among his business partners by firing the EA team, with the result that enterprise architecture becomes a “bad word” deeply embedded in the institutional memory. Roger Sessions wrote a great white paper on driving simplicity through connected enterprise architecture.

4. Policing And Insensitivity To Culture.

I have seen a project manager burst into tears in the crossfire of enterprise architects’ questions during a technical design review. I have been on a 2 a.m. call struggling to comply with unreasonable and obsolete technology standards just to get the chief architect’s signature and meet the budget deadline.

In that particular case, the turning of enterprise architecture into a policing function resulted in its failure. It takes a lot of effort to convince, and regularly re-convince, your business and IT partners of the value of enterprise architecture. A gentle approach makes the function more likely to succeed. The best architects I’ve known spoke softly and carried a really big carrot. They followed Exupery’s advice.

5. Maintaining The EA Artifact Factory.

Some EA teams keep busy documenting as-is states. They have an incredible array of diagrams at their disposal to represent the various aspects of everything. The world of diagrams is addictive, and perfect is the enemy of good when it comes to diagrams.

Instead, these teams should focus on producing frequent, meaningful and measureable business outcomes.

It isn’t easy to come up with good KPIs to measure enterprise architecture. This GAO report clearly shows the challenges of defining good EA metrics in the government sector.

6. Clinging To A Particular Framework Or Tool.

There are more than 80 EA frameworks, and you’ll find no silver bullets among them. The best approach is to read all of the major frameworks, discard most of what you have learned, and blend the remaining 10% in a way that fits your organization’s culture, maturity and business goals. As an example, here’s a lightweight, blended approach for tree huggers. When it comes to tools, go fancy if you have the money. But most of the time fancy isn’t necessary. Visio, Excel, Word, FreeMind, Prezi and a collaboration team site works well. Limit the time spent on selecting tools and frameworks and instead focus on using them.

7. Thinking Enterprise Architecture Equals Technology Architecture.

Most EA programs are initiated by IT and never progress beyond the technology domain. Although technology standards, technology roadmaps and solid engineering practices will produce simpler, cheaper, portable, reusable and more supportable solutions, they don’t align your IT investments with business goals and won’t power your business with technology innovation.

8. Taking The “Enterprise” Word Literally.

“Enterprise” does notnecessarily mean the entire enterprise. It means stepping back and taking a look at the higher-level context before making a decision. Moving architecture to the real enterprise level requires a mature and committed organization. If you try to push the enterprise aspect too far too early, you’ll crash and burn.

This is an example set of templates for TOGAF 9. It includes example artifacts for all catalogs, matrices, and diagrams, and template deliverables.

Example artifacts are as follows:

• Catalogs:
  • Application Architecture: Applications Portfolio Catalog, Interface Catalog
  • Business Architecture: Contract-Measure Catalog, Driver-Goal-Objective Catalog, Location Catalog, Organization-Actor Catalog, Process-Event-Control-Product Catalog, Role Catalog, Service-Function Catalog
  • Data Architecture: Data Entity-Data Component Catalog
  • Preliminary: Principles Catalog
  • Requirements: Requirements Catalog
  • Technology Architecture: Technology Portfolio Catalog, Technology Standards Catalog
• Core Diagrams:
  • Application Architecture: Application & User Location Diagram, Application Communication Diagram, System Use-Case Diagram
  • Architecture Vision: Solution Concept Diagram, Value Chain Diagram
  • Business Architecture: Business Footprint Diagram, Business Services and Information Diagram, Functional Decomposition Diagram, Product Lifecycle Diagram
  • Data Architecture: Class Diagram, Data Dissemination Diagram
  • Opportunities and Solutions: Benefits Diagram, Project Context Diagram
  • Technology Architecture: Environments & Location Diagram, Platform Decomposition Diagram
• Extension Diagrams:
  • Technology Architecture: Network Computing-Hardware Diagram, Processing Diagram
• Matrices:
  • Application Architecture: Application Interaction Matrix, Role-System Matrix, System-Function Matrix, System-Organization Matrix
  • Architecture Vision: Stakeholder Map Matrix
  • Business Architecture: Actor Role Matrix, Business Interaction Matrix
  • Data Architecture: Data Entity-Business Function Matrix, System-Data Matrix
  • Technology Architecture: System-Technology Matrix

Example deliverables are as follows:

• Preliminary Phase: Architecture Principles, Architecture Repository, Business Principles-Goals-Drivers, Organizational Model for Enterprise Architecture, Request for Architecture Work, Tailored Architecture Framework
• Phase A: Architecture Vision, Capability Assessment, Communications Plan, Statement of Architecture Work
• Phase B, C, D: Architecture Definition Document, Architecture Requirements Specification, Architecture Roadmap
• Phase E: Implementation and Migration Plan, Transition Architecture
• Phase F: Architecture Building Blocks, Architecture Contract with Business Users, Architecture Contract with Development Partners, Implementation Governance Model
• Phase G: Compliance Assessment, Solution Building Blocks
• Phase H: Architecture Change Request, Requirements Impact Assessment

Class Diagram

The key purpose of the class diagram is to depict the relationships among the critical data entities (or classes) within the enterprise. This diagram is developed to clearly present these relationships and to help understand the lower-level data models for the enterprise. This diagram is at a high level of representation (conceptual). We are interested here in modeling the main business entities, their properties and relationships.

The TOGAF class diagram as defined is situated at an early, conceptual stage. The highest level allows the essential business notions of enterprise to be represented, without being distracted by organizational or historical complexities specific to each organization. This conceptual level enables you to think about the business, in order to define an ideal organization with regard to this particular business. These entities will be used to define business processes (products handled by processes), and will be derived to define service application components, exchange data between services and repository data schemas.

Data Dissemination Diagram

The purpose of the data dissemination diagram is to show the relationship between data entities, business services, and application components. The diagram shows how the logical entities are to be physically realized by application components. This allows effective sizing to be carried out and the IT footprint to be refined. Moreover, by assigning business value to data, an indication of the business criticality of application components can be gained. Additionally, the diagram may show data replication and system ownership of the master reference for data. In this instance, it can show two copies and the master-copy relationship between them. This diagram can include services; that is, services encapsulate data and they reside in an application, or services that reside in an application and access data encapsulated within the application.

Entity application component: An entity component is frequently derived from business entities, and is responsible for managing the access to the entity, and its integrity.

Interaction application component: Represents the top level components that manage the interaction with elements outside the IS. In most cases, it is a GUI component, such as here a web interface.

Process application component: A process application component is responsible for a business process execution. It orchestrates the tasks of the process.

Utility component: Represents an application component that is frequently reused, and most of the cases bought off the shelf.

Database application component: Represents a repository. In pure SOA architecture, these elements should not appear. However, for legacy analysis or technology architecture, modeling repositories or repository deployment can be useful.

System federation: A system federation is the coarser-grained application component. It assembles systems to federate them, such as in the example of cooperation between different information systems between different companies.

Application: This application component corresponds to legacy applications, off the shelf products, or can be an assembly of application components.

Business Entity: Describes the semantics of the entities in the business, independently of any IS consideration (e.g. storage, technology, etc).

Data flow: Expresses that data (for example business entity) is input or output from a dynamic entity.

Data Lifecyle Diagrams

The data lifecycle diagram is an essential part of managing business data throughout its lifecycle, from conception through disposal, within the constraints of the business process. The data is considered as an entity in its own right, detached from business processes and activities. Each change in state is represented in the diagram, which may include the event or rules that trigger that change in state. The separation of data from process allows common data requirements to be identified, thereby enabling more effective resource sharing to be achieved.

Defining the lifecycle of business entities enables better formalization of these business entities, as well as the determination of the steps that are essential to their management. This very simple state model will be a guide in the definition of business processes, since these processes will themselves have to respect the constraints defined for transitions between states: if a business entity has not passed through all its states within the business processes that handle it, then these are incomplete. If the business processes transgress the lifecyle of the business entities, then they are incorrect.

Data migration Diagram

The purpose of the data migration diagram is to show the flow of data from the source to the target applications. The diagram will provide a visual representation of the spread of sources/targets and serve as a tool for data auditing and establishing traceability. This diagram can be elaborated or enhanced as detailed as necessary. For example, the diagram can contain just an overall layout of migration landscape or could go into individual application metadata element level of detail.

Data security diagrams

IT-related 

Complexity management: Facilitate the scoping and coordination of programs and information systems projects. Manage complexity and describe the interdependencies in a usable manner.

Technical resource oversight: Identify and remove redundancy.

Knowledge management: Manage and share knowledge modularly so it can be visualized across different levels.

IT visibility:  IT resources and systems are more aligned to business strategies and are better placed for responsiveness.

Business-related

Reduction in impact of staff turnover : Capture knowledge from employees and consultants.Provide business solutions from third party organizations consistently so they can conform to the current models.

Faster adaptability: Facilitate knowledge acquisition necessary for changing systems and adopting new components.

Operating procedures improvement: Understand and model business processes. Review and re-engineer processes.

Decision making: Represent an enterprise’s layers and components modularly to let the organization make business decisions in the context of a whole instead of a stand-alone part.

Zachman’s   argument that you have to plan before you do and that you need a view across the whole enterprise is compelling. However, how much of a plan do you need and how much of a view do you need? The strategy of the organization should drive our efforts. The strategy will contain objectives, a statement of its appetite for risk, the timetable for achievement of the goals and the investment it is prepared to make. Architectural efforts must align and produce only the artifacts geared to strategy delivery. If the timescales are tight or money short, then we must be pragmatic and compromise.

However, what often happens is that the objective becomes populate the Zachman Framework for the entire enterprise. Each cell generates a task to create an “As-Is” model and a task to create a “To-Be” model. Each column is taken and given to an architect. The answer isn’t understood and there aren’t any standards for modeling strategy, so “best practice” becomes the guide for producing all the “To-Be” models. This isn’t arrogant, of course, because it is based on logic.

Transformational Architecture

Sometimes, the organization has a “big idea”, a transformation, a merger, a shared services structure, a major change of some sort that requires major investment in IT. The case for architecture is easy … Big change = big design = architecture.

A business transformation places “big architecture” in a clear context with clear objectives and timescales. It gives direction, visibility and urgency.

A major issue for architecture is keeping close enough to the business change to design a solution that meets the needs and has a feasible migration path. Get behind the curve and the consultants and vendors fill the vacuum with half baked solutions that you spend the next 5 years unraveling because they were poorly architected. Get too far ahead and you get accused of trying to bend the business to fit your own pet scheme. Highlight too many problems and you are seen to be “off message”.

How do you get involved? This comes down to influence, relationships and politics because you have no right to be there. Do some stakeholder analysis and plan a campaign to raise your profile in a sophisticated manner that gives credibility and influence as a business person who is worth listening to.

Project Architecture

The concept of an enterprise architect being controlled by a project is nonsense. The job title may include the word “architect” but it is not architecture if the project manager has control of the architect – role is actually a design role. A fundamental part of architecture is that architecting concerns balancing competing demands between projects, between long term and short term objectives, and between different areas of the enterprise. There is a conflict of interest if the project manager controls the architect.

Should architects be allocated to projects? Yes, but only when necessary. When is necessary? When the project may decisions, through pressure of objectives or through ignorance, that pose a significant threat to enterprise business goals. If there is no risk, then there is no need for architectural involvement.

In practice, there is always some risk. There are also constraints on resources, so risk drives the level of involvement required. A triage process is essential to identify up front where to put resources, and integrating architecture into the development process means that you should never lose a project.

Program Architecture
A transformation involves the whole business, doing transformational architecture is by definition enterprise scope. A program typically has a single business theme, e.g. customer service, which has a narrower scope and impact.

Program architecture is a mix between transformational involvement and project involvement. Architects work across the projects within the program to deliver program objectives. They also have a role to ensure that the program follows the enterprise agenda not the program agenda if it differs.

Portfolio Architecture

A program is a set of projects that are related at a business level and it is clear that there are significant inter-dependencies. A portfolio is a set of projects that are managed together for convenience, it may they share a resource pool or a set of business managers. But from a business point of view they are seen as largely independent.

The project management approach is typically to treat these projects as independent from a deliverable perspective but resource constrained. However, the reality is that they are likely to be using the same data, programs or infrastructure.

The architectural task is to carry out a technical impact analysis to understand where different projects hit the same IT asset. Databases and programs should be changed a minimum number of times to minimum costs and risk. Infrastructural changes need to planned as a single exercise to leverage shared infrastructure and to minimize procurement and implementation costs.

This puts timescale and resource constraints into the projects but it achieves greater quality and lower costs. You just have to persuade the project managers and the portfolio board of this.

Operational Architecture
Being service delivery oriented they have clearer and quicker paybacks. However, the skills base and interests of those typically in architecture roles often does not sit well with such an orientation.

An example of an operational architecture objective would be “reduce help desk calls”. If there are 10,000 calls a month and each call costs the IT function $25, then a 20% brings a cost benefit of $600,000 potentially realized by reducing IT headcount or reducing the need for contractors. The business benefit is much higher because each call is lost time to the organization which may mean increased operational costs or lost revenue. My team delivered this within 2 months by reviewing the use of the helpdesk system, implementing better solutions for frequent calls, and redesigning end to end processes. Was this IT focused? No, the organization gets an improved IT service which means it can use its resources to meet its objectives rather than to deal with IT problems.

Other examples could be:

• identify and eliminate repeated problems
• reduce release failures
• reduce call outs
• improve application performance
• improve security
• demise expensive platforms
• improve business intelligence
• speed up the turn around of small changes

Operational architecture is about getting IT’s house in order before pushing the business to do the same. It is about taking the medicine within IT before exposing the business to its rigors. It is about proving the value for money of an enterprise architecture team. It is about delivering tangible benefits to the organization in terms of improved IT service delivery and reduced IT costs. Six months of solid operational architecture performance gives credibility and a great foundation for extending the architectural objectives into the organization.

Procurement Oriented Architecture
Procurement oriented architecture focuses on the purchases that the IT function makes and attempts to optimize them from a financial point of view. Architects review application and infrastructure purchases.

With applications, reuse or extension of existing in house or licensed applications will typically be advised if possible. Minimizing the number of suppliers is also often a goal. The pitfalls are shoehorning needs into inappropriate applications and some suppliers terms have financial “steps” in them that make further licenses prohibitively expensive.

With infrastructure, consolidation is the key to minimizing costs which requires a good knowledge of capacity needs and actual performance. Infrastructure costs typically have financial “steps” which can be exploited. For example, my team saved $5M on an $8M proposal by changing the required spec from 3 top end servers to 5 mid range servers. Did the supplier like it? No. Did they offer the lower range solution? No. We had to do the detail to work out that our requirements could be met by the lower spec machines. The small amount of added complexity and marginally lower flexibility were not worth $5M.

Like operational architecture, this approach is largely confined to within IT but does have significant measurable benefits that can form a foundation for extending architectural work.

Policy Architecture
Architecture policies are the practical instructions for the implementation of architecture principles. They instruct those delivering applications and infrastructure on what they must deliver. They may also set out SLAs or contracts with the business e.g. for data quality.

Some architecture departments’ primary mode of governance of the IT function in relation to architecture policies. This is the creation and maintenance of policies, guidance on policies, policing the process, approving documents, issuing waivers, etc.

This is a very dry role. There is creativity in the research the goes into the formulation of a policy. There is human interaction in the dissemination and mentoring that goes into supporting policies. But often, the architecture function slips either into a police force or to a burdensome bureaucracy.

Sometimes this model is imposed, for example, by the group company on a subsidiary. In this case, efforts must be made to make the approach user-friendly. Architects should guide and support projects so that they automatically comply. They should identify the need for a waiver early and sponsor it. Project managers need to understand the impact of compliance on their projects so that their estimates take any adverse impacts into account. The rationale behind policies should be explained.

Model Based Architecture
The aim of model based architecture is to create models in the hope that they will prove useful. Unfortunately, the usage is often not clearly defined. This means that the models don’t have a real purpose, they don’t have an audience. The result is that they are not built to be used. They become write only models.

Models are tools for architects to do their jobs working with business and IT management and staff to achieve benefits for the organization in line with the objectives of the organization. Models are not an end in themselves.

Silo Based Architecture
A pet hate of mine is to divide architects into business architects, technical architects, data architects, infrastructure architects, solution architects, project architects, etc. It creates silos where the architectures don’t connect.

The application direction is intimately related to the process direction and the data direction and the infrastructure. We can’t pretend that they independent and set up different teams to work on each area separately.

Architects obviously have competencies and preferences in different areas but they must be able to operate competently across all domains otherwise they are not architects.

Another type of silo based architecture organization is to align with the business unit structure. This can result in architecture reinforcing business silos and fundamentally failing to support the enterprise agenda.

How do I organize? I operate a very fluid and flexible structure. I have two tier teams. One tier is the more experienced architects who are capable of running an initiative. Some of the architects have ongoing roles as single points of contact. The rest of the architects form the other tier.

I continually form and reform teams to address specific needs typically the structure changes every few weeks. Each person is generally in 2 or 3 teams simultaneously. Sometimes the teams include people from the business or from other IT areas.

My role is to make sure the approach is working, re-balance the load as necessary, set priorities, and to mentor all the architects to ensure they can deliver to each of the initiatives they are working on.

Opportunistic Architecture
When money is tight in an organization, architecture has a hard time. The number of architects is generally reduced, sometimes to zero. If architecture is still recognized as adding value then as architects we need to take the small opportunities that exist.

This means getting smart over communication. A typical architecture message is about strategy, the long term, flexibility, etc. An organization that has constrained investment is usually looking at short term actions to survive – the strategy is not to spend unnecessarily, the long term will be taken care if we get there. Architects need to get “on message” or lose credibility.

We have to get smart with payback, the organization is looking for rapid payback – 3 months, 6 months, definitely less than 12 months. Therefore, long projects are out, incremental delivery is in. Do something, get some payback, do some more, get some more payback, bring the benefits forwards. Doing this you are helping your organization meet its strategic need to survive, you are showing that you business savvy, you bringing forward the day when the investment constraints get lifted.

We have to get smart with suppliers. Some suppliers will play ball and use value based pricing. This means that they paid based on the value that you receive rather than the capability of the product i.e. you buy a strategic product that gives you a foundation for the future but only pay for what you use. The supplier wins because when you expand usage they additional revenue with minimal presales effort. You win because you get an architecturally sound base to build on. But, you need to get price protection on your future usage so you don’t get screwed on licenses or maintenance.

We have to get smart with projects. You are trying to get each project to put in place a small number of building blocks for the future. You need to persuade them that this is at no extra cost and requires no extra time – they are under pressure. You need a very clear vision, it needs to be pragmatic. If it’s too complex or too big then the small steps will give you too little progress.

Guerrilla Architecture
When you get down to zero and architecture is not seen to add value then the only thing left is guerilla action. You have to be opportunistic but you can’t do it openly. You may also have to resort to sabotage where short term parochial actions are damaging the organization.

You are now playing a dangerous political game. You are exploiting failures to promote more thoughtful planning. You are chipping away at the credibility of others who may have more power than you. You fail if you don’t survive.

You are the one who says “I told you so” and then have a recovery plan. You are the lone voice in the wilderness. Sometime in the future, people will realize and understand that you were right. These people are politicians so they will take your ideas and claim them for themselves. They may even try and discredit you.

Guerilla action is not easy, you will likely lose. But hey, you had already lost, guerilla architecture is a way of retaining your integrity and maybe there is a slim chance of winning.

[Ref: http://chiefarchitect.squarespace.com]

The Open Group Architecture Framework (TOGAF) is the leading enterprise architecture frame work. There are so many frameworks but it may be confusing which one is the best fit for your organization. Especially, when there are more than 20 frameworks that are used to do enterprise architecture. These frameworks can be categorized either as industry specific or corporate propriety. While, we are not arguing the value of these frameworks when they are put into practice in an organization. There have been many result oriented architectures which organizations can claim success from these frameworks.

What makes TOGAF important to the enterprise architecture community is that it is a framework which is built on open standards. This translates to organizations being able to use TOGAF as their enterprise architecture framework for free. They do not have to pay any organization maintenance cost or anything to implement this framework. Companies are always looking for ways to save money especially with cuts in corporate budgets and the need to do more work with less resources. The TOGAF framework has a strong user community who supports the development of the framework. This is one of most adopted frameworks by organizations across the globe. This leads to more opportunities for organizations to find resources in a domain which has been notoriously difficult to recruit qualified enterprise architects capable of understanding how their company does business. Since the company uses TOGAF then they build their architecture the same way that other organizations build their architecture using this framework. The ability of organizations to leverage their resources to capitalize on the benefits of TOGAF would truly make a difference in organizations making better decisions on their technology to support their business needs.

The TOGAF framework has been tried, tested, validated in many organizations around the world. This framework can be used with other existing management frameworks that your company may use. For example, if your company uses ITIL then you can also integrate the TOGAF into the practices of ITIL. There are many benefits from having a framework which is widely used, accepted, and an industry standard. Your organization should pick a framework which will develop the type of artifacts that are needed which are specific to your organization’s needs. When you implement processes, procedures, governance, and structure to manage your enterprise architecture then you should see greater corporate agility, communication, collaboration, and better decision making by corporate executives.