Google and Microsoft

A couple of days ago, some investment fund manager was asked on Bloomberg about Google’s results and its competition. He replied that Google’s main competition is Microsoft’s Bing and Yahoo. This is quite false, in my opinion. Google’s income stream as well as its business model is advertising – not creating search engines just for the fun of it! Today, Google has the lion’s share of the on-line advertising market; Bing and Yahoo don’t even register. Indeed, I would contend that Google’s main competitor is Facebook. This is because Facebook essentially uses its knowledge of its large membership base to target relevant advertising. The main difference is that with Google you do not have to log in as you type your search criteria whereas with Facebook, you need to log in and update various attributes about yourself; hence, the latter relies on push technology and the former on pull technology. On another front, Google’s competitor is Microsoft. The reason being that Microsoft creates and markets operating systems (let’s call them computing platforms) that work on servers and workstations. Further, Microsoft would like to scale this business to mobile platforms such as tablets and mobile phones because that is where the future is. Google, after Apple, is the main provider of a mobile computing platform in the form of its Android operating system. This competes directly with Microsoft’s Windows 8 for mobile devices. So, to sum up, Google’s main competitors are Facebook and Microsoft.

Quite co-incidentally, Microsoft has a small shareholding in Facebook. This leaves Microsoft with some interesting options: a) take over Facebook, b) create a platform similar to Facebook’s and compete with Facebook, or c) sell Bing to Facebook.

The second option would require Microsoft investing in social media at a time when it needs to concentrate on integrating its Windows offerings to work seamlessly across all platforms: from servers to mobile devices.

The first option would be very expensive and contentious prior to Facebook’s IPO. This is because Facebook is touted to go on market with a capitalization of $100 billion whilst having an income of $1 billion. This gives it a pre-IPO P/E ratio of 100 whilst Microsoft is currently trading at a P/E of 11.15. (Remember also that Microsoft is a real business, not just a web-site!) So once the social media bubble bursts and Facebook trades at a reasonable price, Microsoft could act. But that could be four to five years from now. In the meantime, Microsoft could explore option c by selling its Bing search engine to Facebook. That way, Microsoft can concentrate on its core business model and give Google a reason to remain diverted by Facebook. Microsoft’s stake in Facebook will, of course, give it useful intelligence of the social media domain and give it a better opportunity to takeover Facebook down the road should Facebook prove to be profitable in a sustainable manner.

In turn, Google would do well to develop Android and integrate a small footprint version of its search engine with Android so that it can make every mobile device a fast, responsive platform for Google that is tailored to the user’s needs. The search engine, in essence, becomes commoditised and deployed across all those Android platforms. Add to that various social media features that allow users to meet, make choices, tag likes and dislikes, etc. That will take on Facebook’s value proposition as well as Microsoft’s mobile strategy in one swoop. Each mobile device then becomes an outlet for Google’s advertising revenue stream by effectively being a fusion of a Facebook-type social platform, a search engine and a mobile operating system. Only after Facebook and Microsoft have been addressed, should Google set its sights on Apple lest it become distracted on too many fronts.

Implications of Cloud Computing

Suppose you are an investor in an entertainment company such as Sky Broadcasting that uses satellite for broadcasting television channels. Who would pose the greatest threat to your company? Not other entertainment companies, but rather internet service providers and telecoms companies. The reason is the fibre optic cabling of huge tracts of cities and towns will provide these companies the opportunity to bundle telephone, internet and entertainment services in a single package that can be marketed to the consumer at a great discount and, further, provide the customer with the convenience of dealing with just one provider. So, in times of innovation and rapid change, a company’s biggest threat is less likely to come from its competitors in its industry vertical and more likely to come from outside. Much like the motor car replacing the horse buggy at the turn of the 20th century.

Let us consider companies such as IBM and HP – technology companies that are conglomerates of various concerns that, to a large extent, have as their focus the data centre. (The customers of these companies use a centralized model of software delivery where the IT department acts as the arbiter and broker of IT services.) Their immediate threat comes not from their own industry, but from software companies such as Microsoft and Oracle. The reason is that the software companies have an upper hand in terms of defining the license terms of their software when used in cloud computing. And cloud computing creates a prospect of the data-centre companies’ customers migrating to a more loose, federated model of IT service delivery that has the customers’ business stakeholders bypassing their IT departments to obtain cloud services when and where they want.

You may argue that IBM and HP are also software companies as they have an extensive, and quite a good, portfolio of applications. However, almost all of their applications are geared towards the data-centre or for ensuring that the core infrastructure functions well. None of their applications provides a function useful to their customers’ business. In other words, if – as a businessman — you wanted to write business letters, perform book-keeping, reconcile your orders, understand your risk, balance your books, purchase inventory, create fliers, etc., then you would need to turn to a software company such as Microsoft, Oracle or Adobe to help you, not HP or IBM.

So what are the implications for the likes of HP and IBM in future? They will simply gravitate to becoming cloud infrastructure providers or cloud implementers for companies such as Microsoft, Oracle, Google and Amazon. The latter, in turn, will become providers of cloud services. This means that the software companies will essentially take on the role of the customer companies’ IT departments by delivering IT services, via cloud computing, to their customers’ business groups. Whilst HP and IBM will need to concede ground to the software companies, so will their customers. The result will be contraction in business for HP and IBM, and growth for the software companies.

What is a Cloud Service?

Depending upon various implementers’ perspectives, there seems to be much confusion in terms of what constitutes a cloud service. Some use the term application or software interchangeably with service. Others, such as enterprise architects and service oriented architecture (SOA) practitioners, describe a service as a set of related software functionalities, together with the policies that should control its usage [1].

Let us first examine what a service is. In its broadest sense, a service is accompanied by an agreement between the service provider and the service consumer. That agreement may be unspoken or even unwritten. For example, if you go to a café, there is an unwritten agreement that coffee will be served within a certain period and that coffee will meet with your expectations. It is no use ordering a latte and then getting an espresso instead; nor is it any use ordering your coffee and then being told to come back tomorrow to drink it after paying for it. Another aspect of a service is that it is all encompassing in the sense that pretty much everything is a service – even a product. A product, after all, is simply a composition of a number of services: someone had to excavate the raw materials, turn them into a finished product, market the product, transport and sell it to the end user. All those services, then, constitute the product.

In IT, service managers define a service as a collection of IT systems, components, and resources that work together to provide value to IT customers. This definition conforms to ITIL. An important element of this is that, in order to measure and agree upon the value received, two parameters are usually used to assess a service: cost and the service (or operational) level agreement. The service level agreement (SLA) is essentially a contract between the consumer and the supplier in terms of how quickly the service will be delivered (when), its quality (what) and scope (where and how much).

Next, let us examine the cloud. In a broad sense, it provides a level of abstraction to the user in that the user is shielded from the various stages and processes involved in providing the result. So if the user needed a computational platform, he would not need to worry about the operating system, the underlying hardware, the hardware’s power consumption, any storage needed for storing intermediate data, etc. And if the user needed a photograph being processed, then he would not need to worry about the type of software needed, the data being exchanged between various applications to process the image, etc. All he would care about is the cost per photograph and the SLA.

It is important to bear in mind that a cloud service need not necessarily be underpinned by software functionalities. It could equally well be driven by the platform or the infrastructure needs of the user. All cloud services share the common foundation of a business process being provided, whether manually, automatically by software, or indeed any other means. A cloud service could have some manual interaction as part of a workflow that integrates with software and so one can have a combination of functions that provide a service. Moreover, some business value needs to accrue as part of the service being consumed and this business need has to be reflected in a definition of a cloud service.

Therefore, a cloud service is the implementation of a business process, provided through a set of related functional components and resources together with policies that control its usage, and provides business value to its consumers.

The use of an output in terms of business value is required; it ensures that the service will have a utility cost and a benefit associated with it. Further, that cost (in terms of service consumed) and the benefit (as enshrined by a contract or an SLA), will be associated with the service. Finally, it is the business process that gets implemented by the service and can be composed of any type of resource, whether software, infrastructure or even human.

References:

[1] http://en.wikipedia.org/wiki/Service_(systems_architecture); accessed 13-Apr-11.

What Is Enterprise Architecture?

Information Technology (IT) Enterprise Architecture is concerned with translating business needs into IT reality. The purpose of IT is to serve business requirements and aspirations. Enterprise Architecture, in recognising this, commences with the business strategy and the stakeholders that are relevant to the business. A more detailed description for Enterprise Architecture is that it shows the relationships and interdependencies between the organization, its processes and the information, IT system and infrastructure that it uses; in effect, architecture is an effective and consistent set of principles, models and guidelines that give direction and set boundary conditions for IT.

Why Enterprise Architecture?

Enterprise Architecture (EA) is needed in order to make IT a responsive asset for a successful business. Businesses typically need EA for one of two reasons: to create efficiencies in its operations so that it can operate as a lean, agile enterprise or to create value for its customers by incorporating it as part of the enterprise’s business model. The former views IT in the context of a business enabler, and therefore as being part of its core operating model or as infrastructure. The latter, by embedding IT as a business driver, views it in the context of adding value for its customers and thereby as a means of creating profit for the shareholders of the business. In summary, the latter views IT from the perspective of a profit centre whereas the former views IT as a cost centre. These two divergent perspectives have very different focal points; IT when viewed as a cost sink can be outsourced but when viewed as a profit fountain is guarded and kept in-house. Most businesses view IT as a cost centre because they have not reached the maturity in terms of IT adoption and use to be able to leverage it for creating profits. Regardless of the cost-profit perspectives, a roadmap is required by any business using IT in order to understand what the current and future cost of ownership and return on investment (ROI) will be for its IT systems. And in order to create such a roadmap, an idea of the IT assets and how they relate to the business as well as the employees is needed. This is what IT architecture is! So every business needs an IT Enterprise Architecture, regardless of whether it uses IT to cut costs or to make profits.

Further, an IT enterprise architecture provides a strategic context for the evolution of the IT system in response to the constantly changing needs of the business environment. In essence, EA aligns IT with the business. It allows business units to innovate safely in their pursuit of competitive advantage whilst, at the same time, fostering the closest possible synergy across the enterprise’s business units.

Advantages of a good enterprise architecture are:

• A more efficient IT operation.
• Better return on existing investment.
• Reduced risk in terms of regulatory compliance.
• Faster, simpler, and more efficient business operations.

In order to maintain consistency between the principles and models and to provide guidelines that give direction for IT, a framework is needed.

Enterprise Architecture Frameworks

Using an architecture framework should speed up and simplify architecture development, and create an environment whereby IT architects and business stakeholders can communicate to create a more complete coverage and understanding of the desired solution. This understanding across the enterprise enables IT to respond faster to changing business needs.

A plethora of frameworks exist: TOGAF, PEAF, FEAF, IAF, XAF, TEAF, MODAF, DODAF, and Zachman are just some of these. The most commonly used Enterprise Architecture Framework is The Open Group Architecture Framework (TOGAF). This is an open framework that is free, vendor-neutral and technology-agnostic. TOGAF is owned and maintained by The Open Group, a standardization body that also owns the UNIX standard for mid-range operating systems amongst others.

TOGAF views EA from three perspectives: business architecture, information systems architecture (this comprises of data and application architectures), and technology architecture as depicted by Figure 1.

Figure 1: TOGAF’s Perspective of Enterprise Architecture

Below is a description of the architectural components of EA.

1. Business Architecture.

• Business model, strategy, drivers, goals, policies, and operating model.
• Stakeholders and their roles and relationships.
• Functional decompositions, business capabilities and organizational models
• Business processes and workflows.
• Business rules that capture the assigned authorities, responsibilities and policies relevant to the business processes.
• Funding and operational cycles.
• Third-party suppliers of hardware, software, and services; their roles and responsibilities.

1. Data Architecture.

• Metadata: data that describes the enterprise’s data structures.
• Data models: logical and physical models of data that is exchanged between business processes, stakeholders and applications.

1. Application Architecture.

• How the applications execute the business functions and processes by using the data architecture to fulfil business requirements.
• Interfaces between applications as well as between applications and users; these interfaces can be driven by events, messages or data flows.

1. Technology Architecture.

• Platforms: hardware, operating systems, and virtual platforms.
• Middleware; this can be message-oriented (such as WebSphere MQ), applications-oriented (such as Corba) or data-oriented middleware (such as relational databases).
• Hosting of applications on hardware or virtual platforms.
• Local and wide area networks.
• Monitoring and reporting software.
• Security applications.

The Future of Enterprise Architecture

Enterprise architecture is a young discipline and it is still going through a painful process of finding its rightful place in the enterprise. Currently, EA dominates in large enterprises that usually outsource some of their IT functions to a service provider. A need for enterprise architecture will persist in areas such as mergers and acquisitions (where seamless integration or disintegration of organizations is required), and businesses that use IT to deliver value to their customers. These areas will drive the agenda in future.

EA practitioners today form a disintegrated professional body. This is exacerbated by a great variety of professional qualifications vying to represent the career path of enterprise architects through various certification programmes. The future is largely dependent upon these bodies uniting and creating a single, professional certification or validation programme for aspiring enterprise architects. Market forces, in the end, will dictate how EA evolves and these market forces will increasingly be dictated by enterprises that have the greatest need for EA as described in this post.

What it takes to be a CTO

Over two years ago, after three months at EDS as an Architect, I was given the position of an Assistant CTO for Transaction Banking on one of our largest global accounts. The account was a major European bank that was truly international in its reach. Its Transaction Banking business unit was the largest within the bank, and had over 10,000 servers and the largest Oracle 10g grid in the world.

Talk about being thrown in at the deep end!

My job was essentially to take over the reigns of the CTO whilst he busied himself with the bid for renewing our contract with the client; that was a full-time job in its own right. After just three months at EDS, I still had very little idea about the various standards, EDS’s as well as the client’s, or the general processes for getting things done within the huge enterprise. But I was extremely lucky. Sitting right across the desk from me was a well regarded and respected CTO: Gerry Stollof, the CTO for the Group Functions business unit.

Not only was Gerry very clever but he was a very kind gentleman who quickly took me under his wings and became my mentor. He mentored me on the big picture whilst I did the leg-work for my job. One of the first things I learnt from him was what the founder of EDS, Ross Perot, had tried to drill into his employees:

Figure 1: Perot’s Grass-roots Wisdom

So the main gist of my ‘big picture’ training from Gerry was essentially for me to think of myself as the owner and CEO of EDS and our client when doing my job. That really was a paradigm shift and I think the best advice that any CTO could receive. After all, the CTO’s main function is client care, and to represent the client (or at least to believe that he represents the client’s best interests) when doing his job.

Top Gun Project: Week #1

Phew! What a week! The main challenge was in figuring out what the project should be and trying to reach common ground with the various stakeholders. We can categorise the stakeholders into three groups:

1. The Customer,
2. The Account team, and
3. The Top Gun team.

Each stakeholder has their own, seemingly conflicting, requirements. The customer, client X, wants to have some form of virtualization in order to obtain operational cost savings. The account team, represented by the CDE, Mr. Y, feels that virtualization requires too much of an up-front cost in investment and that the returns on investment may not be realized. His idea is to have a simple thick-client build that incorporates Intel VPro functionality and that is distributed using Microsoft SCCM. The Top Gun Program leader, Mr. Z, wants something that will demonstrate thought leadership and show value added to the client from a strategic perspective. My task is to marry the business-as-usual cost reduction (value that would be added to satisfy Mr. Y) with the future TCO reductions that come from strategic planning and positioning (added value that would satisfy Mr. Z).

My idea: do it all! I know that, in most cases, one satisfies nobody by trying to satisfy everybody. But I believe there is enough synergy between the desires of the three stakeholders that I can have a phased project: Phase 1 would provide the base Intel VPro build using SCCM (this would be required anyway to do the other phases) and to deliver a server-as-a-service platform, Phase 2 would be to have a diskless client (thin-client) that would operate in a software-as-a-service environment whereby application streaming is used to provide application virtualization to the cloud, and Phase 3 would be to provide instrumentation and predictive analysis tools to understand the future cost footprint of the server-as-a-service platform that uses software-as-a-service. Combining these two SaaS paradigms would lead us to a whole new paradigm: computing-as-a-service (CaaS).

This is what the FSA (Future State Architecture) would look like with the CaaS paradigm:

I fell into a trap in scoping the project. Everyone was trying to assess what the project ought to be by considering the features of the Intel VPro technology. I joined in by suggesting that we ought to be considering the main use cases and assessing what the cost reductions would for Client X for each of those use cases and then use that to decide what to include in the project. I was wrong! We were all putting the cart before the horse. And it is only when I started thinking about what to write in this blog post that it occurred to me that we ought to look at the FSA first, and then decide from the client’s perspective what technologies and processes will add value. (This blog can be a good quality control tool!) So, in essence, we should be thinking from backwards to forwards in terms of assessing the project scope: from the FSA to what we ought to do now. In that spirit, let’s look at the three phases back-to-front:

Phase 3

The biggest problem, in my opinion, with a cloud computing model or an X-as-a-Service (replace the X with software, server or computing) model is how to price the client’s usage of computational resources. Do we charge a flat fee per user on a monthly basis? If so, there is a danger that we may charge the client unfairly because a sizeable percentage of client users may not be using the applications or resources even though we may be charging them for it. This can be bad for business for HP in the long run. We could, instead, charge on a utility pricing model: pay as you use the service. If so, then do we charge on the basis of bandwidth used per user, the time the service is used or the type of application or service that is being used? Considering that our CaaS paradigm is an amalgam of software-as-a-service and server-as-a-service, I think that the pricing should also be a combination of the application or service used and the time over which the computational resources are used. That way, there is a mapping between the two components of CaaS and the utility pricing model’s components. We then add value by analyzing the usage trends and creating a prediction, using an appropriate algorithm, to let ourselves and Client X know what the EUC estate costs will be over the next week, month or quarter. That can be powerful and useful information to the client, I think. Indeed, if I were the client CIO, I would be over the moon if I had that kind of information.

Phase 2

The idea behind Phase 2 is to create a virtualized, disk-less, workstation build at the client end and to provide applications from a private cloud using application streaming. Indeed, Phase 3 assumes that application virtualization is used at the client end, which may be a thick or a thin client. Intel VPro will be used to identify the user and relate his identity to the applications he uses. We could use Microsoft Azure as a platform for the cloud.

Phase 1

Using a Windows 7 build and Intel VPro technology, Phase 1 would be to create a build that would be distributed via SCCM and monitored using SCOM in order to enhance security, track and maintain assets, and create a standardised framework for future builds that would utilize VPro technology.

Conclusion

Finally, I now have a project that just might please everyone, including myself ;-). The downside is that its deliverables have increased whereas the timeline of three months still stands. This will need to be managed carefully.

The thumbprint of the project is given by the table below.

Project Name: EUC Build Incorporating Intel VPro and Analytics for Provisioning Cloud Resources.

Client: Client X has 50,188 desktops and 39,696 laptops, of which 75% are monitored using Tivoli and the others are monitored with SMS. The different processes and tools used for monitoring and the support knowledgebase required for this creates inefficiencies in cost and manpower. Having a single, composite build is required as a matter of urgency in order to address these inefficiencies.

Solution: We propose the creation of a new HP build that has the following features: a) support for Intel VPro monitoring for asset management, tracking and security, b) analytic tools for assessing and predicting the usage trends of computing resources in the cloud (this will help predict the cost of the resources on a utility-based pricing model), and c) Application virtualization to the cloud using Citrix or VMWare.

Value: Monitoring and support costs will be reduced by $100 per annum per workstation, the immediate savings shall be approx. $ 9 million per annum. But over and above this, there should be considerable value added as a result of the cost and usage projections that we could make for the workstations.

The next step, over the coming two weeks, is to sell this project scope to the three stakeholders and to enlist their support.

Top Gun Program at EDS, an HP company

Last month, I was interviewed to participate in the EDS Top Gun program and was accepted as a participant. So my three months of Top Gun tenure begins from this week.

Top Gun is an intense immersion program where you are given the opportunity to make a difference. Recently, I was feeling that working for a large company such as HP or EDS has a downside: the work you do does not make that much of a difference to the business, the customer or to the world and you can end up feeling like you are wasting your time. Well, the Top Gun program, I think, addresses that: you are given a challenging project that needs to be customer facing and that needs to add value to the client. This work also needs to be done with one or more of our alliance partners. So, overall, the Top Gun program selects those Architects that will create an impact not only for the company, but also for its clients and the industry.

I shall keep you posted on my progress on the Top Gun program on this blog.

Hello world!

Welcome to my new blog on IT Architecture. I plan to use this blog as a kind of diary of the work that I am doing as an Architect.

Why this Blog?

Being passionate about Enterprise IT Architecture, I wanted to write something about it as well as share my experience from work. Hence this blog. If you are as old as I am, you might remember C++ Report. It pushed the envelope for C++ and I still have a complete-ish collection of the magazine stashed away somewhere in my house. Well, I decided to name this blog IT Architecture Report because I hope to push the technology envelope and to honour C++ Report.

Here are the ground rules: apart from the ‘Who I am’ section below, I shall not name any individuals or companies in this blog, without their explicit permission, for professional and ethical reasons; I shall simply refer to them as company X, client Y or Mr. Z.

Who I am

I have been working in the IT industry for the past 15 years, having worked my way up from a Developer to a Lead Architect. (Previous to that, I was an Electronics Engineer in the Aerospace industry for 10 years, but that’s another story!) For most of those 15 years, I specialised in EAI (Enterprise Application Integration) and SOA since their pioneer years in UK. I joined EDS, an HP company, in 2007 as an IT Architect (the HP job designation is Information Systems Architect). My engagement at EDS has been varied: I was an Assistant CTO on the ABN Amro Account (the third largest global account at EDS, where I was mentored by Gerry Stoloff) for 18 months, provided Sales Support for the past 9 months, and I am currently the Lead IE (Integration Engineering) Architect for EMEA on a global account, in the Financial Services industry, that has a TCV of $900 million.

My profile can be found on LinkedIn.