BCS to recognise The Open Group certifications towards CITP status

LONDON, March 9th, 2012 – BCS, The Chartered Institute for IT and The Open Group have signed a new agreement that will allow Open Group certifications to be accepted towards Chartered IT Professional (CITP) status.

The agreement allows individuals who hold The Open Group Certified Architect (Open CA) and Certified IT Specialist (Open CITS) certifications at Level 2 (Master) and Level 3 (Distinguished) to be exempt from the initial review and interview elements of the BCS Charted IT Professional (CITP) process. Applicants will still need to take and pass the BCS breadth of knowledge test as well as be Professional members of BCS to achieve CITP status. The Open Group certifications complement CITP status as they are globally recognised, credible qualifications which demonstrate that IT professionals have the knowledge, skills and expertise required to complete certain jobs.

The CITP assessment process was developed by BCS in response to industry and government demands for deeper expertise and relevance from the IT profession.

Adam Thilthorpe, Director of Professionalism, BCS, The Chartered Institute for IT, explains: “We have assessed The Open Group’s Open CA and Open CITS certifications and are happy that the criteria and processes established by The Open Group meet the level of experience and competence demanded for CITP. Globally there are about almost 6,000 IT professionals who will be able to take advantage of this new agreement when it is launched supporting our objectives to champion global IT professionals and give practitioners the professional development and career support that they deserve. This is important as employers are increasingly demanding CITP recognition from candidates for key IT roles.”

James de Raeve, VP of Certification, The Open Group adds: “This agreement is great news for IT professionals who want to complete both a qualification from The Open Group and achieve CITP status without duplicating effort. The chartered status demonstrates the same degree of professionalism recognised in other chartered professions in the UK and provides independent validation that Level 2 and 3 of The Open Group’s professional programmes are at least equivalent to SFIA Level 5.”

CITP status shows that senior practitioners possess a broad technical knowledge and can demonstrate business experience, commercial accountability and competence in their individual IT specialism(s). Applicants need to have eight to ten years experience with at least three of the last five years in a complex IT role requiring business insight. Professionals also need to demonstrate competence in their chosen specialism(s) and interpersonal skills via an online interview with expert assessors.

Holders of The Open Group certifications forming part of this agreement can register their interest in achieving CITP status through the scheme at: www.bcs.org/citp-theopengroup [1]

About The Open Group

The Open Group is an international vendor- and technology-neutral consortium upon which organisations rely to lead the development of IT standards and certifications, and to provide them with access to key industry peers, suppliers and best practices. The Open Group provides guidance and an open environment in order to ensure interoperability and vendor neutrality. Further information on The Open Group can be found at http://opengroup.org [2].

Enterprise Architecture – TOGAF® 9.1

A revised version of the TOGAF specification, version 9.1, was released on 1st December 2011. There are no new features in this version; it is intended to introduce a number of relatively minor corrections and improvements to TOGAF version, launched at the start of 2009.

Mike Lambert, Chief Technical Officer and Principal Instructor with Architecting the Enterprise, and a core member of the TOGAF 9.1 Specification team throughout the period answers your questions about TOGAF® version 9.1. Click on the following link to read more. TOGAF® 9.1.

Continue reading

Mintzberg’s Ten Management Roles

During my time at Aer Lingus, Organisational Transformation has been a key topic of importance. I’ve learnt that to make real change happen, “people change” is where it is at. Until organisations go back to basics and focus on, and invest in, their core asset (i.e. people), “real change” will never be achieved or sustained.

My interest led me to read about Henry Mintzberg’s management roles and framework. This is something that resonates with me in line with my recent experiences.

To learn more, read on …

Mintzberg’s Ten Management Roles.

 

The Case for 
Application 
Modernization: A How-To Guide for Modernizing the Application Portfolio

Reprinted from Architecture & Governance Magazine (2010-09-15)

As I continued to serve as the Enterprise Architect at Aer Lingus (Dublin, Ireland), I am collecting references from EA journals, magazines and general articles which mirror my experience in shaping the IT Strategy, Enterprise Architecture and transforming People, Process and Technology as part of a 3-5 year programme of work.

Enjoy!


The goal of many businesses is simple: Have the business and IT departments work together to drive growth and innovation, at an affordable cost. Applications play a critical role, and modernizing them is the key to achieving long-term sustainable results. Luckily, by applying a comprehensive and strategic approach to application modernization, organizations can create an application environment that is efficient as well as cost effective for the business. The first step in the process is to assess all of the applications currently in the environment in order to effectively modernize the application portfolio.

The Mess We Get In

Cost: Organizations are spending upwards of 70–80 percent of their technology budget on maintenance and keeping the lights on.1 Whether these costs are infrastructure, application licenses, or support staff, they inhibit the flexibility as well as the ability to innovate and grow the business.

Complexity: Much of the code found in applications today is redundant, and it is common to see multiple instances of redundant applications. In many cases, the applications have been “patched” many times, becoming so bloated that changing them is a risk that threatens business continuity. In addition, the accumulation of applications through growth and acquisitions steadily increases the total number of applications in the portfolio and the level of complexity.

Security: As we move to a world that allows information to flow through many different devices and techniques, providing a security layer to match is difficult, especially if you have to change the applications to implement security. Tactical attempts to modernize applications have served as Band-aids that add to complexity, which only decreases overall security. New regulations on data security exacerbate the problems.

The combination of these issues makes it a struggle to keep applications aligned to the business. The good news is steps can be taken, which offer minimal risk and compelling IT and business benefits.

The Mess Can Be Cleaned Up, But . . .

What’s ironic is that most organizations acknowledge that a formal application modernization program would benefit their organization. In fact, recent HP-commissioned research with more than 200 global organizations conducted by Forrester Consulting showed that 78 percent of respondents believe their organization would greatly benefit from an application rationalization effort. But in contrast, only 56 percent plan to do so. That’s not the end of the contradictions.2

The study also addressed how applications should be modernized versus how they will be modernized. Eighteen percent of respondents believe that 21–40 percent of their applications should be migrated to new technology platforms, but only 14 percent will do so. Forty-seven percent of respondents believe that they should add new features but not modernize up to 20 percent of their applications. Yet 44 percent will modernize. Forty-three percent of respondents believe that their applications should be maintained but not modernized up to 20 percent of the time. Yet 34 percent will modernize.3

Further, respondents were asked to rate their perception of modernization risk before and after employing various techniques. The percentage of respondents that perceived high/very high risk ranged from a low of 39 percent to a high of 50 percent—noting worry about requirements for external help, but most worried about the risk of cost overruns, business process impact, staffing, scheduling overruns, and technical issues. The good news is many organizations overestimated their exposure to risk. After modernization, 25–30 percent of survey respondents actually experienced less risk than they feared.4

The research further found that the top barriers preventing strategic modernization programs were cost, risk, business buy-in, and subject matter expertise. The study also asked respondents, “What would accelerate your plans to modernize/replace your applications?” The number one accelerator by a substantial margin is the ability to bring all parties to the table to reach agreement, followed in turn by increased staff/funding, the ability to make a proper business case, and the ability to lessen risk.

Why is that significant? It ties together many of the points—risks are actually less of an issue than they seem, modernization plans must be relevant to organizational plans, and cost is an ever-present issue. Still, enterprise leaders who do not understand our reasoning for modernization will not support it.

Why Modernize Now

The most compelling reason for a formal application modernization approach is that other organizations, including competitors, are modernizing and gaining a competitive edge.
Secondly, there are many benefits that provide significant outcomes from modernization. Organizations see results that include:

  • Better alignment of business and technology
  • Increased agility
  • Improved security
  • Improved business continuity
  • More balanced technology maintenance spend to 50 percent or less of the IT budget
  • Improved understanding of how business processes are implemented in the applications

A Comprehensive Approach

Transforming the applications portfolio requires a comprehensive approach that treats each application appropriately based on its value to the business. The approach should also address the applications management processes to ensure that the applications portfolio will support the needs of the organization as they change and evolve over time.

Modernizing the applications portfolio itself can be achieved through assessment and a program road map designed to maximize benefits, accelerate ROI, minimize risk, all while identifying self-funding options. HP advocates an approach that consists of three phases: assess, modernize, and manage.

Assess: Assess the complete technology environment including applications, data, and infrastructure. Discover the assets available today through automation, inspections, and code samples. Analyze that information in comparison to business goals as well as priorities, and determine the strategic value of each application to the business. Look for redundancies in applications and identify opportunities for modernization. Finally, decide the best approach to reach the ideal future state and accompanying modernization road map.

Modernize: This phase includes realigning the applications portfolio so that it works for the business. It is designed to improve quality, security, information management, and performance. Multiple strategies are required to modernize an environment. Three basic approaches can help: keep, change, and retire. A modernization road map consisting of all three approaches will maximize benefits of the organization, while reducing costs.

  • Keep: The focus is on making as little direct impact on the application as possible. We would use this approach for performing actions such as extracting business logic from existing applications or simply extracting knowledge for the purposes of documenting the application. It could be used for rehosting applications to higher performance, lowering cost platforms, or wrapping existing applications as services to expose their functions to other systems. This approach is focused on cost savings.
  • Change: This is where we will make fundamental changes in the structures of the applications so they meet the new demands of the business. Examples include replacing legacy applications with packaged ERP or industry applications. It could also be modernizing from legacy languages to new .Net or J2EE based languages. Where is makes sense, it could include going to SOA or cloud computing models. This approach is focused on increasing agility.
  • Retire: For applications that perform duplicate business functions or no longer provide business value, this involves rationalizing the application’s role and capturing and archiving data from the retired application. This process is critical to minimize disruption to existing users and for future business reporting and regulatory needs.

Manage: The third phase is all about gaining the greatest degree of visibility and control to maintain the optimized environment. By understanding the current investments in the application portfolio, IT can calibrate those investments for the greatest impact.
For companies that choose to not manage the application portfolio internally, one viable option to consider is outsourcing to an experienced service provider. Whether an organization chooses to outsource the management of the entire portfolio or only select applications, this phase will need to include the following:

  • Clearly defined standardized service offerings based on ITIL framework
  • Right-size support based on the criticality of each application by choosing from service package tiers
  • Scalable, global delivery capabilities representing the highest industry standards backed by service level commitments
  • Fixed, predictive spending levels that can adjust as the applications portfolio changes
  • The ability to tune investments without renegotiation for quick and easy business alignment

How Modernization Pays Off

Each organization, including its process and benefits, is unique. By taking the steps to complete application modernization, businesses will be able to deliver impressive outcomes. Some of the specific benefits that applications modernization provides include:

  • Increased responsiveness to business priorities and changing demands by eliminating the complexity inherent to legacy systems and server sprawl.
  • Improved productivity for employees and reduced maintenance costs by streamlining complex, legacy systems to more modern, efficient technologies.
  • Faster speed to market with modernized infrastructure and applications.

It is clear that organizations need to take action and truly understand the infrastructure in order to garner the business results that they desire. Applications modernization is one way for organizations to take control of the data center and uncover important information that would not have been made available without the process. Without applications modernization, organizations cannot effectively leverage their portfolios, which slows down innovation and business growth for companies all over the globe.

Notes

  1. 2009 InformationWeek Analytics Survey of InformationWeek 500 executive.
  2. Source: A commissioned study conducted by Forrester Consulting on behalf of HP, May 2010.
  3. Ibid.
  4. Ibid.

File 934

by Larry Acklin, product marketing manager for HP Enterprise Services. He is responsible for global Application Modernization Services.


How to Initiate an Enterprise Architecture Effort in an Austere Environment

Reprinted from Architecture & Governance Magazine (2010-12-10)

As I continued to serve as the Enterprise Architect at Aer Lingus (Dublin, Ireland), I am collecting references from EA journals, magazines and general articles which mirror my experience in shaping the IT Strategy, Enterprise Architecture and transforming People, Process and Technology as part of a 3-5 year programme of work.

Enjoy!


Imagine yourself driving but not knowing where you are going, why you are going there, or how much it is going to cost. Taking a vacation in this manner may not result in the desired outcome. To ensure that your vacation is successful, many factors need to be considered first, such as desired goals and budget limits. Like planning a personal vacation, the federal government and Department of Defense (DoD) must strategically plan their business services, operations, and information systems to achieve their end goals.

Background of Enterprise Architecture Mandates

Enterprise architecture (EA) is currently mandated for federal government organizations. In 1996, the Clinger-Cohen Act reformed the federal government’s approach to information systems acquisition. The intention of this act was to assist in controlling risks, minimizing costs, and improving the performance of federal enterprises. To build upon the Clinger-Cohen Act, the DoD adopted a similar approach in 2003 known as the Joint Capabilities Integration and Development System (JCIDS). Both approaches require the creation of disciplined architecture products to objectively provide key and accurate information for the architecture decision-making and assessment process.

The true intention of these mandates is often lost because federal organizations will sometimes focus on simple mandate compliance rather than the actual goals of the Clinger-Cohen Act and the JCIDS process. For example, EA products are often created to pass reviews, but there is no intent to use them as part of the decision-making process. The EA products should instead be tightly integrated into the strategic planning and acquisition planning activities to be effective and truly meet the objectives of the federal mandates.

Common Problem: 
Translating the Mandates into Practical Use

Because EA products are mandated and may utilize an unfamiliar approach, many organizations become overwhelmed when deciding how to begin their efforts. Enterprises within federal government and DoD agencies are often very complex and usually quite large, as are their private sector counterparts. Tackling a structured, objective enterprise assessment with such complexity and magnitude can be quite intimidating. To add to the strategic planning and EA challenges, organizations often have limited funding to perform the full scope of EA analysis. With the intimidating size of the enterprise architectures and the challenge of limited resources creating an austere environment, organizations often find themselves quite overwhelmed and struggle with how to begin EA efforts.

Key Startup Activities 
for a Successful EA Effort

To overcome an architecture’s complexity and potentially limited resources, MorganFranklin recommends several key startup activities that have proven to be essential to effective EA efforts. In the vacation analogy, in order to not drive aimlessly, the destination, arrival method, and many other factors need to be determined before traveling. In our past experience, there have been organizations that spend large amounts of money to ramp up architecture teams without strongly defining the desired goals and visions of their enterprises. To ensure architecture assessment consistency and overall success, we recommend three fundamental steps to successfully begin an EA endeavor:

  1. Establish and prioritize strategic business goals. What does the organization want to be as it evolves? What business services is it providing to the rest of the community and who are its users? What discriminators or strengths does it want to build or maintain? What overarching policies is it going to embrace?
  2. Create high-level capability and concept views for common vision. Once the goals have been established, how will they be achieved? What is the common vision for the concept of operations? What options are there for new transformational concepts of operations and which concepts currently work successfully?
  3. Capture a catalog of “as-is” processes, systems, applications, infrastructure, services, and standards. Too often the current systems, applications, and infrastructure are completely ignored. It is essential to have a validated, up-to-date catalog of all resources that currently support the organization’s mission set.

How to Realize Immediate Value-Add While Overarching Vision Is Being Set

In an ideal, theoretical world, an organization can wait until the entire “to-be” enterprise architecture has been described and vetted before analyzing and describing a strategic plan forward. However, if organizations were to wait, they would lose valuable architecture assessments that could be completed in the meantime. Organizations can quickly start realizing value from architecture engineering efforts if they are focused on narrowly defined and near-term solutions. While the key startup activities should continue to be carried out by a set of undistracted team members, experience has shown that organizations can have small-scale architecture development successes. The practical and tangible results can also provide the necessary traction and advocacy often needed to continue support and funding for overarching EA efforts.

What are some of these focused architecture analyses? Our experience has shown that an organization can focus on the top-priority systems being acquired and transitioned within the next year. These architecture efforts can make certain that the systems are defined well enough to ensure integration into the greater enterprise. Another focused effort can involve saving operations and maintenance (O&M) costs by analyzing legacy systems and determining what type of redundancies exist. Additionally, a federal organization can explore what potential solutions could be used by obtaining the lessons learned from other organizations’ successes and failures. While the vision is being set, the organization can begin to adopt successful and applicable common practices and technologies.

What If a Formal EA Tool Is Unavailable?

Would you delay your vacation if you owned a Corolla but always dreamed of traveling in a Cadillac? If you did not have the money to buy a new vehicle, you would most likely still take your vacation. For architecture product creation, organizations do not need to wait until they bring in a robust architecture tool before capturing the necessary information. Architecture analysis can occur without a formal architecture tool. The effort can begin by simply using standard desktop commercial off-the-shelf (COTS) products, such as Microsoft Word, Excel, Visio, and PowerPoint. Basic architectural analysis and data collection are essential in strategic and acquisition planning and can successfully occur without a robust tool.

It is important to keep in mind that EA analysis is an ongoing, long-term endeavor. While the architectural assessments should continue despite tool constraints, bringing in a more formal EA tool should be considered for the long-term solution. EA tools are built to support information sharing and expedite architecture product creation. In the long run, a more robust tool will save time and improve collaboration among a large group of architects.

Conclusion

To achieve the vacation of your dreams, capturing the desired goals, objectives, budget, and timeline is essential to successfully arriving at your ultimate destination. EA should be treated no differently. While the ultimate destination is being determined, one can take mini-trips or complete short-term architecture projects that will realize immediate value and potentially provide insight into the end goal. Lastly, the type of transportation, or architecture tool, should not be the primary focus or a limiting factor at the start of an EA effort. Following these guidelines will help any organization get closer to achieving its vision.


Ruth Burgess serves as program manager for IT strategic planning projects at MorganFranklin. She possesses more than fifteen years of experience specializing in systems integration and engineering, with specific experience leading teams developing comprehensive and practical architecture products for several critical government enterprises.

John Forte recently served as technical director at MorganFranklin, specializing in enterprise architecture, information systems modernization, and technology insertion. He currently serves as program manager for national command programs at the Johns Hopkins University Applied Physics Laboratory.

Sharon Stran and Daniel Hughes also contributed to this article.

Free TOGAF 9 Training Offer

FREE TOGAF 9 Training

ENTERPRISE ARCHITECTS is an Australian based company which is offering a compelling opportunity to everyone to receive TOGAF 9 (5-day) training between May-August 2010 in the following locations:

  • UK
  • Australia
  • South Africa
  • USA
If you’re interested in attending a FREE TOGAF v9 worldwide training course – register NOW by clicking here.

ITSM And TOGAF 9 (Applying ITSM to a TOGAF Environment)

Extract of a forthcoming whitepaper to be published by the Open Group.

Executive Summary

This whitepaper considers the alignment of ITSM within a TOGAF aligned enterprise. A key driver for having such an alignment is to remove the business execution silos that come to exist in an enterprise when implementing projects that fall under either ITIL 3 or TOGAF 9. At a high level, we propose to remove such silos by creating a mapping between the two frameworks as well as between ITSM and TOGAF 9. This should create a standard set of artifacts or standard interfaces between those artifacts so that an enterprise may have a common platform for both service management and enterprise architectures. Such commonality is best implemented at the initial requirements establishment phase of an initiative and so the necessary information sharing and processes should be in place at the outset.
 
Our recommendation is for this to happen within the wider TOGAF 9 context where ITIL 3 can be considered as an integral extension of enterprise architecture. This is achievable because there is a lot of synergy between ITSM’s ITIL 3 and the TOGAF 9 framework, especially since TOGAF 9 has shifted to a more service-orientated approach to Enterprise Architecture. 

Authors

Nayan B. Ruparelia, Hewlett-Packard Company

Salim Sheikh, Independent Consultant