Cloud Computing Reshaping the IT Budget

Companies are rapidly adopting Cloud Computing saving money and increasing profits which they are re-investing on their core business capabilities.

Cloud is a pervasive technology adapted from early stage start-ups to Fortune 500. Cloud Computing help start-ups to bootstrap on a shoe-string budget. The power of the cloud computing pricing model comes from turning CAPEX expenditure into OPEX. With no upfront costs start-ups can spin up servers on a low budget and scale-up as they grow. Large companies on the other hand save from this on-demand usage basis model. For example let’s take a 100 compute node Big Data Cluster used for only 1 hour per day for Data Analytics, the machines would be turned on-demand for the computational needs thereby having a large cost savings as opposed to having dedicated hardware.

Rackspace Hosting together with Manchester Business School conducted a study of 1300 organisations in the UK and US revealed that:-

·         56 per cent have been able to increase profits through using cloud services

·         49 per cent have been able to grow their business through use of the cloud

·         60 per cent say that cloud computing has reduced the need for their IT team to maintain infrastructure, giving them more time to focus on strategy and innovation.

References
1. 88 per cent of cloud users point to cost savings according to Rackspace Survey
https://blog.rackspace.com/newsarticles/88-per-cent-of-cloud-users-point-to-cost-savings-according-to-rackspace-survey/
2. The Economic and Strategic Benefits of Cloud Computing
https://www.computereconomics.com/custom.cfm?name=postPaymentGateway.cfm&id=1931

Enterprise Architecture - Common Mistakes by Beginners

Acknowledgements

Thank you to everyone in the “TOGAF for Architecture” group who contributed to this article.

This article concentrates on common mistakes made by Enterprise Architecture beginners and advice on how to be a better EA, and have a better Enterprise Architecture practice.

Lack of Understanding

- Not developing an effective understanding of the key stakeholders and their motivations.
- Not knowing that other disciplines have great material (i.e. Systems Engineering is very rigorous but not necessarily suited to enterprise architecture).
- Trying to do even IT-architecture (let alone a proper 'architecture of the enterprise') without a very solid understanding of 'the business of the business'.
- Lacking the business skills.
- Going by the book only, not taking some courses on EA and thus losing the opportunity to really understand the concept and getting feedback from experience EA practitioners.
- Not understanding that Information Systems are the prime tools to manage and operate an organization. In other words information management is the focus of EA.
- Inventory errors (confusion about components and classifications).
- Within an EA team, the strengths and weaknesses of the staff have to blended and directed to leverage strength and mitigate weakness. if the team is inexperienced, then the problems are compounded.

Lack of good judgement

- Treating EA as a project (rather than as an ongoing capability).
- Need to be more aligned to business needs at times rather than theoretically perfect approach to solve a problem.
- Stakeholder errors (confusion about the 'real' stakeholder, too much/too little time with the right/wrong stakeholder).
- Not having the insight to draw upon multiple methodologies in the tailoring phase to create useful artefacts.
- "Deliver white éléphants". A recent EA projects in public sector with easily two thousands person-days investment and the solution is not used today. They made a damned good and costly picture of the organisation at that time, but it didn't evolved and it's now put on a shelf. Too much unusable documentation. It's a pity for ratepayers and don't give good press for EA projects.

Failing to perform due diligence

- Failing to realize that some EA work is already going on in the company but under a different name and as a consequence failing to interlock with them.

Failing to Plan

- Not developing a communication plan to address the concerns of those stakeholders.
- Failing to understand how EA is IT centric! (it's the IT assets, which - due to complexity - require architectural attention in addition to regular planning work) and ending up making EA too general and diluted.
- Adopting a specific EA framework without any tailoring and thereby preventing the EA practice from delivering 'fit-for-purpose' architecture. Instead, it would become a 'systematic' replica of documentation.
- Selecting a methodology and applying it without tailoring it to the near term objectives.
The type of project requires immediate business benefits quickly or the project will be unplugged rapidly. It’s a fact. Thinking big too fast enters in tedious project that never finish or brings any result. EA has to evolve as the benefits it brings. Reaching a first phase that returns benefits even to one only or few business units is preferable.
- Defining a serial process, when an iterative process is needed.
- Allowing the stakeholders to have fuzzy scope/purpose/objectives for the EA work.
- Not realizing that the time frame between the as-is and to-be models can or should have interim steps with their own gap analysis.
- Trying to do the whole architecture in one big multi-year hit (rather than as small-scale actions in context of a larger picture, and in conjunction with existing change-projects).

Failure in prioritization

When you take an organisation verticals (HR, Finance, IT, Marketing) trying to move through an entire vertical in the Business Architecture for example and then moving to Data Architecture in the BDAT stack. Problem is the effort involved in fully defining the enterprise at the business level is usually so great and so costly that stakeholders get scared and pull the plug before ever moving to the next level. Whereas if you take the vertical zig-zag you explore one line of business or business capability in all BDAT levels, then repeat for other lines of business, zig zagging up and down. Doing this allows you to bite off chunks of Business capability that can be tackled in a reasonable amount of time and cost and lead to tangible results quickly. This encourages the stakeholders with real results that they want to see more of.

Failing in Communication

- Failing to set and communicate some guiding principles
- Lack of Information brevity. Creating too much information for a time-poor audience
- Use of architecture jargon, and a lack of use of familiar business terminology
- Failing to understand the significance of confidentiality. Many business plans are kept confidential and can't be reflected in widely distributed material (like EA artefacts) so appropriate management is needed. A symptom of this is the inexperienced analyst / consultant who doesn't grasp that the business manager they have engaged with may not be able to tell them the whole story due to confidentiality.
- Not tailoring the communication artefacts to the expected audience and the frequency of delivery
- Selecting tools that are difficult to publish to corporate websites
- Not defining or publishing a taxonomy (how artifacts relate) or an ontology (artifact definitions and uses) 

Failing to Market

- What is an Enterprise Architecture – Poor Education to Stakeholders about what value EA will provide in the long run.
- It's hard to make things change and change can seriously hit the bottom line so resistance to change comes with the territory. You're now dealing with people that make decisions and that carries responsibilities. I try and respect that, and understand that the current state is often a consequence of a myriad of decisions taken in isolation many years ago that were probably right at the time. Warm people up to new ideas, talk over coffee, and don't avoid the difficult stakeholders. Be prepared to sell your ideas/findings in 30 seconds or 30 minutes - these CxO types are busy. I have no problem walking people out of the building for a couple of minutes of airtime! 

Failing to Execute

- Concentrating on the as-is (the "we have to understand where we are before we can plan to move forward" fallacy)
- Failing to interlock properly with the business decision makers (often - paradoxically - by creating a "business architecture" which is how the EA team think the business ought to look but is actually detached from actual strategies and plans).
- Trying to do too much all at once. EA is something that evolves. A key to success is to identify the aspects of EA which are important to support planned / intended business change and focus on them.
- Not selecting, modifying and creating a set of reference architectures (part of tailoring)
- More Change or Transformation Centric: Advisory based on change rather than EA as a base recommending change (Considering Customers, Organization as a whole, Departmental level changes and last but not the least Decision at various levels aligned to Organizational Goals)
- Process rigidity (forcing the 'correct' sequence) and errors (can’t start, can’t finish, get stuck)

Failing to Mitigate Risk

- Thinking risk is not concern of EA 

Failure in Governance

- Failing to implement effective governance
- Reinventing the wheel when reference material (architectures) already exist
- Trying to act as the 'architecture police'
- Trying to tell solution-architects how to do their job 

Failure in Information Management

- Not creating reusable artefacts when documenting/defining the enterprise
- Lack of Repositories for EA Artifacts – Visualization of Process and Data Interactions and relation to organizational Goals at various levels can be accessed at certain repositories and further constant updates in Enterprise Architecture is not there in relation to recent goals and objectives

Quality Issues

- Failing to customise (and be pragmatic about the use of) a methodology or framework
- Deliverable errors (artifacts at the wrong level of detail, wrong focus, poor execution)

Lack of Emotional Intelligence and Perception

- Inability to understand the "human psyche"
-  Stubborn in their beliefs and fail to empathize with management and their superiors
- I know it all philosophy, trying to show they are smarter, trying to show the light to everyone in the company from the CEO downwards
- Visualization of a holistic view- EA gets focused to silos and sometimes considered as an increment to IT Architecture
- Ivory Tower Architect syndrome: EA advisory and consulting is not consistent and aligned to Goals and Objectives of an Enterprise
- Vanity/arrogance, thinking that knowing EA makes you better than the business/IT people that hired you, thus not really listening to them and doing your EA.
- Non-architect mind-set. In other words, the architect should adopt the mind-set that enables him/her to capture the 'full picture' and 'long-term' approaches rather than 'on-spot' solutions.
- A belief that Enterprise Architects should be telling the business stakeholders how to enable their business capabilities.
- Lack of soft skills of the practitioner

Some good advice from experienced EAs

- Get good architectural principles to start off with. Standards, policies, patterns etc. can take a very long time to collect. You can start to govern with principles as an absolute minimum. Anything less is sage advice and wisdom. Collect the others as you go along, and get the right people to own them. 
- Communicate with Purpose
- Be a good "political" leader. Try not to be abrasive, keep egos out and work out good solution acceptable as a team; do not seek "self glory"
- Follow the budget. EA is hard without a solid mandate and the best way to ensure that is to align arch governance with project governance - budget milestones are a great way of ensuring projects deliver.
- EA is about bringing business value through IT. If you endeavour on 1+-year efforts on defining the EA, you're on the wrong path. Do the 20% that gives you the 80% of the answers needed.
- Keep it Simple
- Stay evergreen - yourself and your EA. Constantly listen to the business, listen to the IT, and ensure that your EA is giving value also today. Govern hard when it makes sense, but listen to when the EA is out-dated, and modify it to still meet needs.
- Adopt and Adapt 
- Don't worry about failing, and fail fast when you do. Second time around you'll do a better job by learning from your mistakes. The hard fact is a lot of EA teams struggle the first time they try. Divide and conquer can work.. Keep your raw data, take lots of notes, and take time to understand why something isn't working.
- Use their language. By all means geek out when you're talking to your peers, but when you're talking to your stakeholders talk to them in their language. Words like "(business) service", "product" and the trinity of "Vision/Goals/Objectives" mean different things to different people. You have enough to sell them, don't waste it arguing what a Product is.
- Love the Ops team. The teams running the systems day to day are usually the closest to them and can be a goldmine of information for your current state analysis.
- Don't ignore the Project Management Office. They often have a great view of all the finance spend and you can often find the guerrilla IT lurking in far corners of some functions.
- Enable, don't disable projects. I've worked with EA's who love to say no. I've worked with better ones that suggest alternatives, or point out opportunities to help projects move forwards.
- Use a model and build a repository. Don't get hung up on which one - they all have their strengths and weaknesses . Unless you have a real need don't make it more complicated than it needs to be. It doesn't need to be fancy. Excel is better than nothing.
- Keep track of your architectural debt. Waivers are a fact of life in EA. If a programme isn't implementing your "target" architecture for good reasons (like time or money), try and at least steer it in a way that increments the capability in the right direction and can be easily replaced when the time comes. 
- Enjoy the job. Not many people get to solve problems and attack hard challenges all day.

TOGAF in a nutshell

TOGAF is an Enterprise Architecture Framework. It is focused on Strategic Planning, Execution, Governance of an IT Vision and coming up with a roadmap for Technology Transformation.

Preliminary Phase
Select the Architecture Framework TOGAF TRM or III-RM this forms the basis of the foundation architecture. Next establish Architecture Principles. Business, Data, Application and Technology Principles should be established. The principles should be robust, consistent and stable. An example set of Data Principles: - i. Data is an Asset, Data is Shared, Data is Accessible.

Architecture Vision
The Architecture Vision is the elevator pitch statement that could sell the proposed development to stakeholders.

Eg:- 1. Improve the Return on Capital Deployed, Increase Operating Efficiency, Improve the Quality of Service Level across the Technology Landscape.

Business Architecture
Describe the Baseline (As-Is) and Target (To-Be) Business Architecture. The Architecture could be tabulated as BPMN Models, UML Use Case diagrams.

Information Systems Architecture
Describe the Baseline (As-Is) and Target (To-Be) Application Architecture, and describe the Baseline (As-Is) and Target (To-Be) Data Architecture. These would consist diagrams for Application Eg:- Portfolio Catalog, Interface Catalog and for Data Eg:- Conceptual and Logical Diagrams, Data Migration Diagram, Data Life Cycle Diagram to name a few.

Technology Architecture

Describe the Baseline (As-Is) and Target (To-Be) Technology Architecture, Environment Location Diagram, Platform Decomposition Diagram are some of the Artefacts produced from this exercise.

Opportunities and Solutions
Perform gap analysis and arrive at solutions. You may choose to build a new system, obtain a COTS product or Decommission and existing system. A new system would be represented by a Solution Buiding Block, while existing systems would be ABBs (Architecture Building Blocks).

Migration Planning
Plan the migration from the Baseline to Target Architecture (Business, Data, Application and Technology) and produce a detailed Implementation Plan and Migration Plan.

Implementation Governance
The information for management of various development projects is brought together.

Architecture Change Management
Continual monitoring of environment for changes. Ensure changes to the architecture are managed in a cohesive manner. New Requests for Architecture work are created as required.

What is an Architecture Viewpoint ?
TOGAF documentation for Data Architecture a Planner would require a Data Entity View, the Designer would need Logical Data View, Standards View, System Engineering View the Builder would need Physical Data View.

TOGAF provides a set of Catalogs and Diagrams to address different viewpoints.

                                                                      

Enterprise Architecture Tools

1. Sparx Enterprise Architect
This is my favorite tool, it comes with a TOGAF Repository, UML, Archimate, BPMN, modelling can be done using Sparx EA. This is an enterprise grade tool. The top tool of choice for any EA practice.

2. Archi
This tool is an open source Archimate modelling tool. It is a very user friendly tool, and a top quality open source tool. I would recommend Archi for anyone looking for a tool for Archimate drawings for free.

3. Bizagi Process Modeler
Bizagi is an Open Source BPMN Modelling tool. While it may not be the most user friendly option, it does pack  the benefits of a free BPMN tool.

4. CA ERwin
The Computer Associates ERwin tool is an ERD (Entity Relationship Diagram) tool, which is capable of delivering data models, for data architecture. This is an intuitive tool for anyone with knowledge on ERDs.

Introduction to Enterprise Architecture

What is Enterprise Architecture ?Enterprise architecture (EA) is a discipline for proactively and holistically leading enterprise responses to disruptive forces by identifying and analyzing the execution of change toward desired business vision and outcomes. – Gartner
Enterprise architecture (EA) is "a well-defined practice for conducting enterprise analysis, design, planning, and implementation, using a holistic approach at all times, for the successful development and execution of strategy. – Wikipedia

Current Enterprise Architecture Frameworks
TOGAF, Zachman, AGA, FEAF, DODAF.

TOGAF

The TOGAF framework has the Architecture Development Method an Iterative approach at its core. An architecture blueprint of the baseline and target architectures for Business, Data, Application, and Technology is created with the migration plan arriving at an Architecture Roadmap.

Zachman

The Zachman Framework has 6 perspectives (Planner, Owner, Designer, Builder, Subcontractor); the framework asks 6 basic questions (What, How, Where, Who, When, Why). This a simple but effective framework used by different industry sectors.

FEAF (Federal Enterprise Architecture Framework)
FEAF is based on 5 reference models Performance Reference Model (PRM), Business Reference Model (BRM), Service Component Reference Model (SRM), Data Reference Model (DRM), Technical Reference Model (TRM).

AGA (Australian Government Architecture)

AGA is based on FEAF (Federal Enterprise Architecture Framework), AGA consists of 5 inter-related reference models Performance, Business, Services, Data and Technology. AGA is mainly used in the Government Sector.

DODAF (Department of Defense Architecture Framework)

This Framework is specifically geared towards complex systems. DODAF includes a Design Process and Artifacts which cover viewpoints.

Which framework is best for Banking and Finance?
1. TOGAF
2. Zachman

TOGAF is heavily used in the Banking and Finance industry and is a good fit for the industry. The ADM iterative approach is appropriate for the complex operating environments of Banking and Finance.

The following is a matrix developed based on my research on the EA frameworks and industries that these are used in.

Industry/ EA Framework	TOGAF	Zachman	FEAF	AGA	DODAF
Agriculture, Forestry, Fishing and Hunting
Mining	X
Utilities	X
Construction	X
Manufacturing	X
Wholesale Trade
Retail Trade	X	X
Transportation and Warehousing	X	X
Information	X
Finance and Insurance	X	X
Real Estate Rental and Leasing	X
Professional, Scientific, and Technical Services	X
Management of Companies and Enterprises	X
Administrative and Support and Waste Management and Remediation Services
Educational Services	X
Health Care and Social Assistance	X	X
Arts, Entertainment, and Recreation	X
Accommodation and Food Services	X
Other Services (except Public Administration)
Public Administration	X		X	X	X