What goes around comes around...

I noticed recently an article that stated that India's IT Industry was going to grow to around $100bn by 2010. Whilst not wishing to argue about the figures in one way or another, I would however like to comment about why the tremendous growth.
For my sins, I would like to openly declare that I am, in fact, actively engaged in offshoring some IT effort for a company I am presently consulting for, but I think this does provide me with more than a little insight into the reasons behind the move to offshore.
Everyone talks about cost as being the major decision point for many companies, indeed Indian rates are far below those of American or European counterparts, and Chinese rates are even lower, but the reasons are actually around more decision points such as Quality, Service Management and Flexibility.
Taking Quality first, we find that Quality and Cost are of course deeply connected. We would like higher quality (don't we all), and particularly in view of the very real pressures upon us in Financial Services in regulatory compliance with SOX and Basel 2. To get the right quality, we have to engineer new processes for quality and regulatory reporting where we didn't before either because of resource or cost constraints. Thus by having a cheaper workforce, we are gaining extra bandwidth to improve quality. Because of this, our Indian counterparts are indeed providing much higher quality than we've been able to achieve ourselves purely because they're the only ones actually being paid to do it; and what's more they're making a really good job of it.
The second decision point is around Service Management. In the past with our incumbent suppliers or internal workforce we've been unable to impose any kind of Service Management on our basic production. This has been due to a number of reasons (i) Again, we've not had the money to perform the engineering of the processes, (ii) We've been restricted by unions (iii) We've been unable to get ourselves into the mindset (this applies to all of us) that we're actually providing a service to someone. It is around this area that there is a warning shot against our new offshore friends; that we're organising ourselves for managing our Services in new flexible ways, and think here about the very rapid growth in interest in ITIL based Service Management models, and it's this very model that will enable us to deploy and switch services rapidly and with good rationale.
The third decision point is around Flexibility and, as referred to under Service Management, this enables us to switch services amongst many suppliers. India today, China tomorrow, and back to the US or Europe when we come back full circle again.
I would like to come back to what kind of skills are suitable to be offshored, in the next blog…..

Business Aligned

You must have heard of the new kid on the block; he's called Business-Aligned and he's making waves everywhere. You've got Business-Aligned IT, Business-Aligned Technology and you've got Business-Aligned Enterprise Management; the kid is everywhere. Let's see what exactly he's up to (and what he's not).
Look around you and see who's using Business Alignment as a selling tag and you'll notice a proliferation of Platform vendors selling their wares; their message is that Business-Aligned means consolidated hardware, blade servers, and on-demand computing. Yes, they're right, the business wants does want economy, and the business does want flexibility, but the business also wants much more, it wants true alignment.
In large corporations, it is very often the case that the IT budget creeps steadily upwards, year upon year, and the business can't see where it is all going to; they don't often see the benefit of nice new features, or nice new machines. The extra money is going towards maintaining the every-increasing base of technology out there; every new system bringing its own maintenance overhead in people to support it, people to look after the new technologies, and of course, people to program the systems using nice new languages and tools. The reason that this base of technology goes on increasing, is that we don't seem to turn anything off; we don't retire the old systems and technologies. More stuff, more people, more cost, more maintenance.
Technique number one is to get Requirements right in the first place; right at the start of our projects. Try using Tom Gilb's techniques for fully-formed requirements definition, capturing not just the "What", but also the "When", and "How Fast".
Technique number two is to map all our Applications to Business Functions and re-use where we find matches, we consolidate new functionality in existing Applications, and we retire Applications as part of the project that replaces them.
Technique number three in this great alignment strategy is to map Applications to the Business Processes that they automate; we can then relate real Business Transactions to transaction flow in our Applications, and map our Applications to their Host servers and, coupled with Business Systems Management techniques, we can relate System Health, Problem Management and Risk right up to the Business Process.
Isn't this Business-Aligned IT, or should we just buy more boxes?

What is this Enterprise Architecture thing?

To begin to define Enterprise Architecture we're going to have to start by asking ourselves what Architecture is anyway, and how and whether it differs from Software Design and then we're going to have to talk about what Architects actually do.
In Program Design, in the years gone by, we tackled low-level design problems, and since we didn't have Industry-Standard Operating Systems, we started by figuring out how our programs get loaded and executed, how they were arranged internally, how we sorted our data, how we stored our data, and how we managed to run two pieces of work simultaneously in the same machine. We standardised all this knowledge and put it into Operating Systems and Programming Languages, and we moved onwards and upwards into the challenges of driving our graphical displays, relating our data items, and multi-threading our programs.
Today, very few people are working on designs for relational databases and windowed operating systems now since they have passed into "been there, done that, standardised it", since we moved on, Onwards and Upwards.
Soon our evolution brought the concept of Programming Models, later called Patterns; standard ways of putting Program Code, Programs and Systems together. We also saw the first of our Architecture Models in Client-Server. Client-Server was very popular in this concept and brought about the final demise of Program Design, with its "no-brainer" model; Put together a Data Model in a Relational Database, build standard clients using such languages as Visual Basic, PowerBuilder, and Delphi, interact with that data. Transfer data into and out of the Database, and you have a simple System; no real Design, just a pattern, a model. Many, many Systems were build that way and are still there now. Programming started to become plain Engineering.
This is may be where we started to think about Design and Architecture at this point, in that Architecture is just a higher form of Design where we are more concerned with the Structure of the solution rather than its detailed Design; since we're assuming that the Design inside the structure is standardized in some way. The oft-quoted analogy of Architecture of buildings says it all here, you "Architect" buildings, but you "Design" rooms; it's just a question of level.
Architecture today is concerned with the Structure of the solution; how the boxes on our diagrams interact, not what happens inside the boxes. We look at the classic challenges of Confidentiality, Integrity and Availability of these boxes and their interconnects, and, when it comes to the Technologies used, we're interested in the strategic value of those technologies, and not what happens behind the Application Programmer Interfaces.
Architecture itself is evolving, moving to higher levels, and also specializing in the process. Today we talk of Technical Architects, Data Architects, Information Architects, Security Architects and Network Architects as lateral specializations, and on the other hand, Enterprise Architects are Technical Architects working at a higher level of abstraction.
This is where I fit into the great scheme of things, in Enterprise Architecture; working on the twentieth floor rather than the basement. I believe that Enterprise Architecture deals with the problems of Technology on a grand scale, on an Enterprise level, and the Strategies and Processes, and how IT aligns with Business needs. Your mileage may differ, let me know if you agree.
Please feel free to follow me and interact with me as I attempt to share with you some of the challenges, some of my experiences, and a lot of definition; hopefully stimulating you with some of the ideas from the world of Enterprise Architecture; Onwards and Upwards……