List of Enterprise Application Architecture Patterns

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

Example/sample ISO/IEC 27001:2013 ISMS scoping statements

Sample 1

The Information Security Management System (ISMS) applies to the provision of trusted and managed information security services to internal and external customers of <ORGANIZATION> in accordance with the ISMS Statement of Applicability revision xx, dated xx-xxx-xxxx

Sample 2

As stated in the Information Security Management System (ISMS) Statement of Applicability, revision xx, dated xx-xxx-xxxx, the ISMS encompasses <ORGANIZATION>’s Information Technology Division Office, Computer Lab, Storehouse and Computer Classroom, covering business activities relating to the provision of operation, maintenance and management of Internet and Web services and systems.

Sample 3

The provision of e-Business solutions that are fully integrated to deliver the complete process and management of e-Business components including: workflows; contacts; e-mail; bulletin boards; news; events; traffic analysis and audits on a secure hosted platform, 24 hours a day, 365 days a year, as per the Statement of Applicability approved by senior management on xx-XXX-xxxx.

 

Note: be aware that if you narrow the scope of your ISMS, you are also going to:

  • Reduce the implementation costs to some degree, although you will still need to implement a comprehensive management system to be certified compliant to ISO/IEC 27001;
  • Reduce the business benefits compared to a more broadly-scoped ISMS; and
  • Have to define security interfaces for information flows and processes that span or extend beyond the in-scope area to the remainder, since everything outside the scoped area is relatively untrustworthy.

Mandatory requirements for ISO/IEC 27001:2013 certification

Mandatory requirements for certification

ISO/IEC 27001 is a formalized specification for an ISMS with two distinct purposes:

  1. It lays out, at a fairly high level, what an organization can do in order to implement an ISMS;
  2. It can (optionally) be used as the basis for formal compliance assessment by accredited certification auditors in order to certify an organization.

The following mandatory documentation (or rather “documented information” in the curiously stilted language of the standard) is explicitly required for certification:

  1. ISMS scope (as per clause 4.3)
  2. Information security policy (clause 5.2)
  3. Information security risk assessment process (clause 6.1.2)
  4. Information security risk treatment process (clause 6.1.3)
  5. Information security objectives (clause 6.2)
  6. Evidence of the competence of the people working in information security (clause 7.2)
  7. Other ISMS-related documents deemed necessary by the organization (clause 7.5.1b)
  8. Operational planning and control documents (clause 8.1)
  9. The results of the risk assessments (clause 8.2)
  10. The decisions regarding risk treatment (clause 8.3)
  11. Evidence of the monitoring and measurement of information security (clause 9.1)
  12. The ISMS internal audit program and the results of audits conducted (clause 9.2)
  13. Evidence of top management reviews of the ISMS (clause 9.3)
  14. Evidence of nonconformities identified and corrective actions arising (clause 10.1)
  15. Various others: Annex A, which is normative, mentions but does not fully specify further documentation including the rules for acceptable use of assets, access control policy, operating procedures, confidentiality or non-disclosure agreements, secure system engineering principles, information security policy for supplier relationships, information security incident response procedures, relevant laws, regulations and contractual obligations plus the associated compliance procedures and information security continuity procedures.

Certification auditors will almost certainly check that these fifteen types of documentation are (a) present, and (b) fit for purpose.  The standard does not specify precisely what form the documentation should take, but section 7.5.2 talks about aspects such as the titles, authors, formats, media, review and approval, while 7.5.3 concerns document control, implying a fairly formal ISO 9000-style approach.

Structure of the ISO/IEC 27001:2013 standard

ISO/IEC 27001:2013 has the following sections:

0  Introduction – the standard uses a process approach.

1  Scope – it specifies generic ISMS requirements suitable for organizations of any type, size or nature.

2  Normative references – only ISO/IEC 27000 is considered absolutely essential to users of ’27001: the remaining ISO27k standards are optional.

3  Terms and definitions – a brief, formalized glossary, soon to be superseded by ISO/IEC 27000.

4  Context of the organization – understanding the organizational context, the needs and expectations of ‘interested parties’, and defining the scope of the ISMS.  Section 4.4 states very plainly that “The organization shall establish, implement, maintain and continually improve” a compliant ISMS.

5  Leadership – top management must demonstrate leadership and commitment to the ISMS, mandate policy, and assign information security roles, responsibilities and authorities.

6  Planning – outlines the process to identify, analyze and plan to treat information security risks, and clarify the objectives of information security.

7  Support – adequate, competent resources must be assigned, awareness raised, documentation prepared and controlled.

8  Operation – a bit more detail about assessing and treating information security risks, managing changes, and documenting things (partly so that they can be audited by the certification auditors).

9  Performance evaluation – monitor, measure, analyze and evaluate/audit/review the information security controls, processes and management system in order to make systematic improvements where appropriate.

10  Improvement – address the findings of audits and reviews (e.g. nonconformities and corrective actions), make continual refinements to the ISMS

Annex A  Reference control objectives and controls – little more in fact than a list of titles of the control sections in ISO/IEC 27002.  The annex is ‘normative’, implying that certified organizations are expected to use it, but they are free to deviate from or supplement it in order to address their particular information security risks.

Bibliography – points readers to five related standards, plus part 1 of the ISO/IEC directives, for more information.  In addition, ISO/IEC 27000 is identified in the body of the standard as a normative (i.e. essential) standard and there are several references to ISO 31000 on risk management.

Why Enterprise Storage? How to deploy on-premise Enterprise Storage?

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.

 Terms frequently associated with enterprise storage include storage networking, which is the linking of storage devices with each other and other computer systems, and storage management, which includes technology and processes that help organizations control and maintain their storage systems.
Enterprise Storage Implementation
When you decide to deploy a new enterprise storage system, you face a number of choices. First, you must decide whether to design and build your own storage system or to utilize a cloud-based storage service. If you decide to use a cloud computing service, you won’t have to make very many decisions about the hardware and network architecture, because the cloud vendor will handle those for you. Generally, the deployment steps for cloud storage will be fairly simple: Select a cloud service that meets your needs, sign up for the service and configure it to work with your existing applications and networks. Your most important task will be researching the services to make sure that you get one that can meet your needs and work with your current infrastructure.
How to deploy on-premise Enterprise Storage?

The following three steps for deploying on-premises storage networks involve setting up the physical hardware and cables, migrating data (if necessary), configuring the devices and testing the system.

1) Choose a Storage Media

If you decide to build your own storage system, you’ll have to make some additional decisions .For example, you’ll need to select which storage media to use: Tape, hard disk drives (HDDs) or solid state drives (SSDs). Tape is the least expensive medium, but its performance and capabilities generally make it suitable only for backup and archive applications. HDDs are more expensive than tape, but they offer the higher performance necessary for primary storage. SSDs cost the most of all, but they offer much better performance and reliability than either tape or HDDs. Many organizations use a mix of tape, HDDs and SSDs, and some storage devices themselves include a mix of HDDs and SSDs.

2) Choose a Storage Architecture

You’ll also need to decide on your storage architecture. Enterprise storage can include direct-attached storage (DAS), storage area networks (SANs) or network-attached storage (NAS) devices. DAS devices connect directly to an individual PC or server and don’t offer the same collaboration capabilities as networked storage. However, you do gain collaboration benefits from SAN and NAS devices. SANs provide block-level storage for access by servers, while NAS devices offer file-level storage for access by end users. Many organizations use a combination of DAS, NAS and SAN devices.

3) Choose a Network Protocol

You’ll also need to choose which network protocol you’ll use. Your options include the Internet Protocol Suite (TCP/IP), Fibre Channel Protocol (FCP) and Internet SCSI (iSCSI) protocol. The type of storage architecture you select will impact which network protocol(s) you can use. For example, Fibre Channel and iSCSI are SAN protocols, while NAS is an IP storage protocol. Fibre Channel over Ethernet (FCoE) has emerged as one way for Ethernet and Fibre Channel networks to converge.

 

Integration is the biggest challenge of Enterprise Architecture

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.

Gartner Identifies Ten Enterprise Architecture Pitfalls

“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.”

Top IT Service Management challenges…

  1. IT cost transparency. Something has still got to give in terms of what IT costs — IT is and will continue to be a sizable expense to the business. The IT organization is spending the business’ money, and so the business wants to know whether it is being spent wisely (and who can blame them). How many IT shops know if they are investing the business’ money wisely outside of projects?
  2. Value demonstration. Is IT still just a cost center or has your IT organization been able to translate IT investment into demonstrable business success? I still rather somewhat cheekily say that “if we could demonstrate the business value derived from IT, surely we would be being asked to spend more rather than having to respond to corporately mandated, quick fix, end-of-year budget cuts.”
  3. Agility. The speed of business change continues to dictate a rapid response from IT that many struggle with — as a simple example, yesterday my nephew told me of his five-week wait for a laptop at the bank he recently joined. Not only is it speed and flexibility, it is also “agility of mind.” A change in I&O mindset that asks “why not?” rather than “why?”
  4. Availability. Nothing new here (again). The business needs high quality, highly available IT (or business) services. The difference is in business expectations and available alternatives. For a number of reasons, the business continues to be less forgiving of IT failure and, again, who can blame them.
  5. “Personal hardware.”  End user devices will continue to be a big challenge for IT in 2013. Whether it is the fact that our “internal customers” are unhappy with their “outdated” corporate laptops or the fact that they can’t have corporate iPads or the whole “can of worms” that is BYOD (bring your own device), personal productivity hardware will again be a battleground of business discontent in 2013.
  6. Support and customer service. For me, support is one thing and customer service is another; ideally IT delivers both. That it is ultimately about supporting the consumption of IT services by people rather than just supporting the technology that delivers the IT services. And that service-centricity by frontline IT staff is not enough; it needs to be all IT staff. The same is true for customer-centricity.
  7. Cloud. As cloud adoption continues, are we looking at cloud as a technical or business solution, or both? Do we know enough about the status quo to make informed decisions about moving IT services to the cloud? Probably not; yet for many, cloud is the answer. But I still can’t help think that we haven’t really taken the time to fully understand the question.
  8. Mobility. BYOD comes into play here again, but I think that a bigger issue is at hand — that we are still technology-centric. We all hear talk about MDM (mobile device management) as “THE big issue.” IMO, however, this is old-skool-IT with the device a red herring and of little interest to the customer (unless IT is providing outdated devices). Your customers want (or at least we hope that they continue to want) to access your services any which way they can and need to. Mobility is about people.
  9. Compliance. Whether it’s internal or external regulatory compliance (or governance), most of the above will potentially have a negative knock on to compliance whether it be SOX, software compliance, or meeting internal requirements for “transparency and robustness.” With everything going on elsewhere, it is easy for me to imagine degradation in internal control, not reacting to new risks as a minimum.

How can organisations using ITIL adapt for Cloud Services?

The first point to make here, is that ITIL is, and will continue to be, an IT Service Management toolkit.

That means that you don’t have to be using ALL of ITIL, ALL of the time – the methodology can be adapted to suit the needs of organisations – the key thing is to put your organisational requirements first, and not follow bureaucracy for the sake of it.

Second, ITIL has been formed on IT Service Management best practice and will continue to evolve to reflect the needs of IT departments the world over.

Public vs Private Clouds:

Well run IT service Management systems have always had to apply different models to different systems – they will continue to evolve, The focus if IT teams will have to move away from operational aspects of infrastructure to managing the diverse environments that public, private and hybrid Cloud environments will bring.

Configuration Management Database:

Anyone who uses ITIL will know the importance of the CMDB – however doesn’t necessarily mean inflexibility. A well implemented CMDB can make things more agile in fact.

No doubt, the way organisations use the configuration management database will need to be tweaked for Cloud – however the message is the same – use ITIL as part of a sensible and flexible IT Service Management infrastructure and you will be able to account for any changes that new technology brings.

 

What issues does ITIL face with Cloud Computing?

Some of the problems that ITIL will face with Cloud Computing include:

  • Because Cloud and SaaS apps are based on a pay-as-you-go model, they have the potential to operate under the radar of ‘traditional’ IT service management infrastructure – particularly with relation to procurement
  • Dealing with Private and Public cloud services will require different approaches. Public clouds are great in terms of their cost savings but cab be less reliable, especially when you look at security, compliance and service level agreements. These problems are not there with Private cloud services – but they don’t come cheap. As a result, many organisations use hybrid services.
  • ITIL’s configuration management database (CMDB) – is designed to hold information about  assets and resources that exist in an IT environment – what happens when those resources don’t physically exist any more?!

9 ITIL Implementation Challenges

ITIL implementation is no cakewalk. ITIL impacts your entire organization — your business, your IT department and your in-flight projects. The most common implementation challenges include:

1. Management Commitment

The biggest problem ITIL implementations face is when executive management approve the ITIL program but then fail to follow through with strong sponsorship support.

2. Resistance to ITIL

ITIL represents a broad organizational change that is always resisted. Departments, teams and individuals tend to defend the status quo.

3. Project Culture

ITIL isn’t a project with a completion date. It’s a set of processes that must be continually improved. There are plenty of organizations who “do” ITIL and then move on to something else. This approach always fails.

4. ITIL for the sake of ITIL

Organizations that seek a rubber stamp from ITIL (e.g. ISO 20000 certification). Such organizations see little business value in ITIL and seek to minimize implementation costs at the expense of true ITIL success.

5. Business Acceptance

ITIL isn’t transparent to the business. For example, it may change the way that business submits change requests or opens support tickets.

It’s important that business be a strong supporter of ITIL from the start (program initiation). Otherwise, ITIL may be viewed as bureaucratic nonsense. ITIL implementations are rarely successful without business buy-in.

6. Big Bang

ITIL has numerous processes. Each ITIL process has a large organizational footprint. Full implementation of ITIL is best done in phases. A big bang ITIL implementation has the potential to disrupt IT and business operations.

7. Naive Implementation

Throwing ITIL over the wall and hoping it takes hold.

8. Tools

ITIL isn’t a technology. However, it’s nearly impossible to implement ITIL processes without technology. Technology implementation is often amongst the greatest ITIL challenges.

9. The Moving Target

Many organizations that were in the middle of ITIL V2 implementation were thrown off track by the considerable changes in ITIL V3.

Challenges:::: Enterprise Architecture

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.

Why Enterprise Architecture fails??????

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.

TOGAF® 9 Template Artifacts and Deliverables

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

Fundamental of Data Architecture while using TOGAF

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.

Identify the possible states of the entity (for example, a document can be “under-Creation”, “under-Revision”, “approved”, and so on), and then define the possible transitions between each states. A state must be a stable data situation: when no action is executed on it, the data is always in one of the identified states.

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 migration can be expressed at conceptual, logical or physical level. Application communication diagrams can also be used to express the data migration. The “migrate” dependency is the key element to formalize migration.

Data security diagrams

Data is considered as an asset to the enterprise and data security simply means ensuring that enterprise data is not compromised and that access to it is suitably controlled. The purpose of the data security diagram is to depict which actor (person, organization, or system) can access which enterprise data. This relationship can be shown in matrix form between two objects or can be shown as a mapping. The diagram can also be used to demonstrate compliance with data privacy laws and other applicable regulations (HIPAA, SOX, etc). This diagram should also consider any trust implications where an enterprise’s partners or other parties may have access to the company’s systems, such as an outsourced situation where information may be managed by other people and may even be hosted in a different country.

Large diagrams can become hard to read. It is recommended that you create one data security diagram per business entity, and/or per participant (typically a role). In particular, diagrams focused on actors and their missions can provide habilitation links. Diagrams may also be focused on the external access to the system, that is on which data the external actors can access.