Sunday, 24 November 2013

To Be or Not To Be TOGAF Certified

I have been an independent IT Architect for sometime. I always kept asking myself why I need the certification as I am doing similar job. What is the incentive for me to put extra effort to study and spend extra money?

Let’s see what open group says why it’s important:
‘’IT Architecture is acquiring increasing recognition as a necessary discipline for ensuring that the design and implementation of enterprise-wide IT properly addresses and supports the needs of the business. TOGAF is an open, industry standard framework and method for IT Architecture, developed and continuously evolved since the mid-90's by representatives of some of the world's leading IT customer and vendor organizations.
The introduction of a certification program for TOGAF enables large organizations (both private and public sector) to standardize on this open method for IT Architecture, and so avoid lock-in to the proprietary methods of major consultancies.

It is an important step in making IT Architecture a well-recognized discipline, and in introducing rigor into the procurement of tools and services for IT Architecture.
The value to licensees is the ability to use the term "TOGAF" together with The Open Group Certification Mark in association with products and/or services that support the TOGAF framework and it’s Architecture Development Method. Individuals are also entitled to membership of the Association of Enterprise Architects (AEA) at no additional cost.’’

Does that convince me? Does that make me jump out of my seat and spend around £1500 pound for training and certification.

Few questions to ask yourself which will help to decide the take the plunge:
1 – Is my company following TOGAF framework or planning to in near future?
2 – Am I a budding Enterprise architect who wants to be move next step in the carrier ladder?
3 – Have I always worked in vendor specific and need the knowledge of vendor neutral framework?
4 – Am I part of the senior management team who needs to understand TOGAF to drive the initiative in my company?
5 – I am an IT contractor who wants to build industry recognised qualification to help serve my Enterprise customer better?
6 – Do I need a classroom based expensive training or online training?
7 – Is my company sponsoring for the training and certification cost?
8 – Is my company a consulting one and getting certified would open more opportunities for me?
9 – Is other architecture framework like Zachman is more relevant to my area of work?
10 – The jobs I am looking to apply for looking for TOGAF certified applicants.

Lots of the questions above been yes for me. I have taken the plunge and gone for the online training for the certification. I will let you know in my future blog how did it go and how to prepare for the certification exam.

Saturday, 23 November 2013

Qualifications & Skills Required for Enterprise Architects

Enterprise architects work with stakeholders, both leadership and subject matter experts, to build a holistic view of the organization's strategy, processes, information, and information technology assets. The role of the enterprise architect is to take this knowledge and ensure that the business and IT are in alignment. The enterprise architect links the business mission, strategy, and processes of an organization to its IT strategy, and documents this using multiple architectural models or views that show how the current and future needs of an organization will be met in an efficient, sustainable, agile, and adaptable manner.

Enterprise architects operate across organizational and computing "silos" to drive common approaches and expose information assets and processes across the enterprise. Their goal is to deliver an architecture that supports the most efficient and secure IT environment meeting a company's business needs. It is important for Enterprise Architects to continue building their skills.

Vendor Specific - The popular vendor certifications from Cisco, Microsoft, VMware and Oracle in the respective areas such as networking, operating systems, virtualisation, middleware and databases are important credentials.

Vendor Neutral - Certification in recognised vendor-neutral architecture frameworks like TOGAF and the Zachman Framework.

The Open Group Architecture Framework (TOGAF) is a framework for enterprise architecture which provides a comprehensive approach for designing, planning, implementing, and governing an enterprise information architecture. TOGAF has been a registered trademark of the Open Group in the United States and other countries since 2011.

The Zachman Certified™ - Enterprise Architect program enables working professionals to develop the theoretical and technical skills needed in the 21st century workplace. More and more companies are looking for employees or consultants who can demonstrate command and deliver results in this wide body of knowledge. Some of those now even making Zachman Framework™ certification a requirement.

Other Skills/Soft Skills – Enterprise Architect needs to raise the bar and perform above the expected technical competencies in order to be a good infrastructure architect. Project management skills and soft skills such as listening and persuading come into their own when communicating how technology addresses business problems.

Useful extra certifications in related disciplines that comprise soft skills include ITIL, PRINCE2 and PMP. Recruiters may also seek skills and experience of writing materials such as bids, request for proposals (RFPs) and presentations.

However, certificates are no substitute for experience, and the enterprise architect shouldn’t lose sight of their techie roots. They need to stay on top of technical developments in order to retain the respect of their team.

Thursday, 21 November 2013

Enterprise Architecture Frameworks

Enterprise Architecture Frameworks
The field of enterprise architecture essentially started in 1987, with the publication in the IBM Systems Journal of an article titled "A Framework for Information Systems Architecture," by J.A. Zachman. In that paper, Zachman laid out both the challenge and the vision of enterprise architectures that would guide the field for the next 20 years. The challenge was to manage the complexity of increasingly distributed systems. As Zachman said:

The cost involved and the success of the business depending increasingly on its information systems require a disciplined approach to the management of those systems.

An enterprise architecture framework (EA framework) defines how to create and use an enterprise architecture. An architecture framework provides principles and practices for creating and using the architecture description of a system. It structures architects' thinking by dividing the architecture description into domains, layers or views, and offers models - typically matrices and diagrams - for documenting each view.

Types of enterprise architecture framework
Nowadays there are now countless EA frameworks, many more than in the following listing. Today, four dominate the field: the Zachman Framework for Enterprise Architectures, The Open Group Architecture Framework (TOGAF), the Federal Enterprise Architecture (FEA), and Gartner (formerly, the Meta Framework).

Consortia-developed frameworks
·         ARCON – A Reference Architecture for Collaborative Networks – not focused on a single enterprise but rather on networks of enterprises[18][19]
·         RM-ODP – the Reference Model of Open Distributed Processing (ITU-T Rec. X.901-X.904 | ISO/IEC 10746) defines an enterprise architecture framework for structuring the specifications of open distributed systems.
·         Good enough architecture methodology – a methodology based on experiences, results and best-practices gathered through real-life implementations of various building blocks that altogether provide a realizable architecture and working solutions.
·         IDEAS Group – a four-nation effort to develop a common ontology for architecture interoperability
·         ISO 19439 Framework for enterprise modelling
·         TOGAF – The Open Group Architecture Framework – a widely used framework including an architectural Development Method and standards for describing various types of architecture.

Open-source frameworks
Enterprise architecture frameworks that are released as open source:
·         GOD, a generalist observation methodology, contains an enterprise architecture framework based on observation, an innovative certified approach provided in the SDFL Department of DUJ.
·         LEAD Frameworks.[24] LEAD is an abbreviation for Layered Enterprise Architecture Development and is the only community-driven open source EA framework built upon international standards that is in use today. LEAD consists of frameworks, methods, and approaches that are all integrated with to each other and with supporting maps, matrices, and models.
·         MEGAF[25] is an infrastructure for realizing architecture frameworks that conform to the definition of architecture framework provided in ISO/IEC/IEEE 42010.
·         Praxeme, an open enterprise methodology, contains an enterprise architecture framework called the Enterprise System Topology (EST)
·         TRAK – a general systems-oriented framework based on MODAF 1.2 and released under GPL/GFDL.
·         SABSA[26] is an open framework and methodology for Enterprise Security Architecture and Service Management, that is risk based and focuses on integrating security into business and IT management.

Defense industry frameworks
·         AGATE – the France DGA Architecture Framework
·         DNDAF [20] – the DND/CF Architecture Framework (CAN)
·         DoDAF – the US Department of Defense Architecture Framework
·         MODAF – the UK Ministry of Defence Architecture Framework
·         NAF – the NATO Architecture Framework

Government framework
·         European Space Agency Architectural Framework (ESAAF) - a framework for European space-based Systems of Systems [21][22]
·         Government Enterprise Architecture (GEA) – a common framework legislated for use by departments of the Queensland Government
·         Federal Enterprise Architecture Framework (FEAF) – a framework produced in 1999 by the US Federal CIO Council for use within the US Government (not to be confused with the 2002 Federal Enterprise Architecture (FEA) guidance on categorizing and grouping IT investments, issued by the US Federal Office of Management and Budget)
·         Nederlandse Overheid Referentie Architectuur (NORA) – a reference framework from the Dutch Government E-overheid NORA
·         Treasury Enterprise Architecture Framework (TEAF) – a framework for treasury, published by the US Department of the Treasury in July 2000.[23]

Proprietary frameworks
·         ASSIMPLER Framework – an architecture framework, based on the work of Mandar Vanarse at Wipro in 2002
·         Avancier Methods (AM)[27] Processes and documentation advice for enterprise and solution architects, supported by training and certification.
·         Integrated Architecture Framework (IAF) – from Capgemini company in 1993
·         CLEAR Framework for Enterprise Architecture – Atos Origin's Enterprise Architecture Framework
·         Dragon1 - An open Visual Enterprise Architecture Method recently recognized by The Open Group as Architecture Framework
·         DYA framework developed by Sogeti since 2004.
·         Dynamic Enterprise Enterprise architecture concept based on Web 2.0 technology
·         Extended Enterprise Architecture Framework - from Institute For Enterprise Architecture Developments in 2003
·         OBASHI – the OBASHI Business & IT methodology and framework
·         Information FrameWork (IFW) – conceived by Roger Evernden in 1996
·         Purdue Enterprise Reference Architecture developed by Theodore J. Williams at the Purdue University early 1990s.
·         Solution Architecting Mechanism (SAM)[28] – A coherent architecture framework consisting of a set of integral modules.[29]
·         Zachman Framework – an architecture framework, based on the work of John Zachman at IBM in the 1980s

Friday, 15 November 2013

3 Key SOA Design Patterns

design pattern is a general reusable solution to a commonly occurring problem within a given context in software design. A design pattern is not a finished design that can be transformed directly into source code. It is a description or template for how to solve a problem that can be used in many different situations. I always found the following three key SOA design patterns very useful:

Agnostic Capability
Agnostic services implement logic that is common to multiple business problems. Separating agnostic logic into discrete services facilitates service reuse and composability.

Enterprise Service Bus
An ESB acts as a message broker between consumers and services. The ESB can perform message transformations, routing and connect to applications via a variety of communication protocols. 
More details can be found in my previous blogg.

Authentication Broker
An authentication broker assumes responsibility for authenticating consumers. Consumers are issued a token they can use to access services.

More details can be found in

Thursday, 14 November 2013

Enterprise Service Bus

From my childhood, I always liked reading different story books. I could read story books in my mother tongue (Oriya) and English. Whenever I saw any story book in a other language, I always wonder how it would be to read it as well. For that to happen, I have to learn all the languages. Certainly, that’s not going to happen for an 8 year old kid. Is it not possible have a machine to translate it in my brain?
When I came across ESB some years back, I knew this is what I wanted in my childhood. No, it is not a google translator. It is a way to understand different stories in different language (i.e. in software world, providing a single architecture to distribute information by masking differences among underlying platforms, software architectures, and network protocols).
What is it then?
Definition from Search SOA says ‘’ an enterprise service bus (ESB) is a software architecture for middleware that provides fundamental services for more complex architectures. For example, an ESB incorporates the features required to implement a service-oriented architecture (SOA). In a general sense, an ESB can be thought of as a mechanism that manages access to applications and services (especially legacy versions) to present a single, simple, and consistent interface to end-users via Web- or forms-based client-side front ends’’.
As per IBM, An ESB provides the connectivity to implement a service-oriented architecture (SOA), reducing the complexity of integrating applications and services.
There is a decent 3-part series over at IBM regarding ESB that's pretty concept oriented and vendor agnostic (for the most part)
When to use ESB?
The use of an ESB is worth considering when three or more applications or services need to be integrated. A simple point-to-point integration is significantly easier and much more cost-effective when connecting two applications. An ESB can also be worthwhile if services are going to be incorporated from external service providers over which the company has no control. The ESB can then be used to monitor the service level agreements that the external provider guarantees. The impact of the adjustments to service contracts can further be kept to a minimum, as the ESB continues to provide a stable interface while making the necessary changes to the messages.
If many different protocols, such as HTTP, SOAP, and FTP, are to be used and standardized to one protocol like SOAP, the ESB can perform the necessary protocol transformation. If services are to be consistently incorporated into an architecture to be able to receive, process, and produce messages, then the use of ESB is also suitable.
You should read this article on "Don't use an ESB unless you absolutely have to". It was written by the CTO of MuleSource, one of the most popular open source ESB's available.
If messages need to be reliably and securely processed, the ESB can simplify the implementation of transactional message flows between two heterogeneous transactional data sources. This sounds more like ETL (Extract, Transform, and Load).
ETL is geared toward data movement, typically in batch (high volume) modes across the enterprise. It is “pull” technology and works on user’s demand or on schedule. ESB is a “push” technology, sending messages when they occur i.e. real time messaging.

Refer to the link ( for information about when to use ESB vs ETL.