CityArchitect

Who are you working for anyway?

noreply@blogger.com (CityArchitect) — Wed, 03 Jun 2009 22:09:00 +0000

One of the main reasons that I've felt a little uncomfortable with working for big corporates has been the increasingly onerous Terms and Conditions of employment that I've had to endure. I've always felt that out of the hours of 9.00 to 5.30 my time was my own, I was free to express myself in any way that I wanted.
Now, the only freedom I really wanted was that of being able to go home and work on my own projects; the things that burnt inside of me, the things that needed to be expressed. Increasingly nowadays, the big corporates are assuming that you work for them 24 hours a day and anything you do is either (i) Theirs entirely, IP and all and (ii) Theirs to censor. In other words they believe that they own you lock stock and barrel.
It doesn't really work that way, we'll all expressing ourselves in Blogs, contributing to Open Source, and generally interacting with other people and organisations on a commercial and semi-commercial basis all the time out there on the Internet.
I've got to be able to say that I'm doing it for someone else, or I'm simply doing it for myself.
To be fair, there are many big corporates that are so frightened of their public image, or worried about compliance, that they have to assume that whenever their employees communicate, they communicate on behalf of that corporate. And it seems it's not enough that we use private email addresses.
We are fast moving into an age where we will be working for many more companies simultaneously, and sharing our time, interests, tools and materials. Many companies nowadays don't have a permanent workforce at all, they have outsourced, sub-contracted or employed the big consultancies on projects. How do they ensure seperation of concerns and Intellectual Property? And how do we maintain the right identity?

Bringing it all together

noreply@blogger.com (CityArchitect) — Wed, 01 Apr 2009 22:08:00 +0000

How many databases does it take to change a lightbulb? and Databases and ear discomfort and Bringing it all together
And you may remember that, along with some helpful comments, we arrived at the idea that it was closely related to the number of business processes that a company runs......
Well, we never really closed on it, never got to the position where we could mathematically say whether we had the right number in a particular company or the wrong number.
Why do I want to know, why do I get so hung up on this kind of stuff? Well, I guess I'm always trying to get at our inefficiencies, our lack of quality, and would like to be able to say that we have too many systems or too many technologies. You have to be able to say what the optimum number is in the first place.
It's all very well to go into a company as a consultant and say "Gee, 3467 databases does seem quite a lot, I think you may have a problem here...". I'd like to be able to authoritively say "Based in your current business Model, and the number of High-Level Business processes that you carry out, your optimum number should be 42, so you are over-deployed by a factor of 82.55. Based on current metrics and industry practice, you could achieve over-deployment factors of 13.67, saving you 2893 databases and $10M every year in Support, Maintenance and Licensing."
Ha!
But of course, we haven't got this. We can only stand there wringing our hands, talking to the floor and saying "Weeeellll, I kinda think we've got a problem" and "I think we could kinda save some money here" and "I kinda think that this is contributing to our high levels of operational risk"
What is the optimum number of databases for any company, in any industry?
Well, I'm going to stick my neck out here and say that it's more than 10 but less than 20, but I do have a high-level list of suggested business processes to back this up...
What's your take?

Reasons, reasons, reasons

noreply@blogger.com (CityArchitect) — Fri, 20 Mar 2009 23:08:00 +0000

In the last Blog entitled "The number is 10" I tried to re-ignite earlier blogs on optimising the database space, and came to the conclusion that a company should have 10, possibly 20, databases. I had some helpful comments as well (thank you Vincent). I'd like to continue this theme.....
The reasons why we exceed the optimum number of databases are many and varied:
1. We use Vendor products that don't provide perfect coverage of the data space for the business function they cover. This coverage can be more or less of that optimum data space, but either way, additional, external, data coverage is required to facilitate usage of that Vendor product. There is further rationale available around this....
2. We use many Vendor Products and Systems to cover the same business function. Enterprise Architects spend a large amount of their time reviewing IT Projects promoting re-use and rationalising the Application space in the sometimes vain attempt to stop this kind of proliferation.
3. The Systems using these databases may be planned to be replaced at some time (presumably and hopefully moving towards a more perfect model). If you have hundreds or even thousands of business applications, this could be quite a waiting queue.
4. Some of the databases are merely Integration points for data concentration and transformation. We do this, a lot, particularly to concentrate data for reporting, but mainly for "Impedance Matching" between Systems.
5. Reporting databases proliferate freely. The data is never in the format you want it. This is more about the feeling that Data WareHousing is difficult and costly and the tools difficult to use. Many, many databases are used in Back Offices everywhere to massage data for Reporting in differing ways and to facilitate investigations.
6. Personal Productivity. During the Year 2000 efforts, I worked at a company where we inventorised all Access Databases on file servers and, for a department of 120 people, found 8500 databases. Further investigation showed that some of them were tracking lottery numbers, but many of them were merely copies of existing data in a more manageable and accessible form produced to make the owner more efficient. Of course, this introduces a bigger problem than technology proliferation, it introduces Operational Risk. Much more could be said here....
There may be other reasons here that I'm sure you can help me with....

Pass it on.....

noreply@blogger.com (CityArchitect) — Tue, 17 Mar 2009 23:08:00 +0000

I'd like to keep to this theme about database proliferation offering you another little story from my travels through the magical world of Megabank.
I was taking a look in an emerging business area; we were creating a new investment product for a particular market. As is usual in investment banking, sometimes with these more esoteric products you can price them and produce them using manual procedures when there are very low numbers involved. This group had started to handle the product semi-automatically using Microsoft Access and Excel to handle tabulating the deals and to do some of the processing, but things were moving too quickly, business was booming.
One of the days that I visited the area I was most amused (secretly) to see 50 people, all with spreadsheets and databases of various forms open, shouting across the floor at one another saying "Who's got the Order Sheet open?, I can't get it" and "OK, finished James, it's all yours". The entire group were using Excel, Access and shouting to process the business.
One of the reasons I was there was to look at audit problems, and particularly the very high number of fails and exceptions in the process. Investigation showed that it was plainly the handling of the Excel and Access files that was the problem; they were being updated and copied by many people at the same time, with multiple versions in existence.
And, on pointing out the obvious problems to them, some of these people even said that their data was just harmless copies! Even though they went on to make business decisions and carry out other processes based on that data.
Bad data governance, no identifiable safe update process, and no sense of "gold copy". Nightmare. I was really surprised that these people hadn't understood that data is the lifeblood of a company, and that it needs treating with care and reverance.
It was crying out for a system to be developed, and a single source of truth that everyone could work to, a single, gold copy database managed inside a single defined process.
Over the following months as a tactical measure, we helped them build the gold copy database based on Microsoft's SQL Server, which worked very well, reducing the number of fails and exceptions dramatically. Until one evening when the office cleaner pulled out the plug on the server................but that's another story!

At last a number.........

noreply@blogger.com (CityArchitect) — Sun, 15 Mar 2009 23:07:00 +0000

I'd like to come to a close on this stream of consciousness around my perfect number of databases by summarising where I think we've got to.
By databases, I mean actual Operational Data Stores that contain the data that support the business process. I don't mean convenience copies (although I don't believe they should exist at all), and I dont mean Integration databases (which are largely transitory), and I don't mean databases that exist in Vendor Products that don't fit the whole of the business function for which they supposedly cover (this is probably a big cop-out).
The list of Systems supporting the major Business Functions that use a database looks like this:
1. CRM - Supporting the Sales Force with Prospect and Current Customer details for the purposes of new and repeat sales.
2. CRM - Service - The Helpdesk for existing Customer service.
3. Sales Order System (Possibly by major Product Lines - I believe there could be multiples)
4. Manufacturing System, Stores (Posisbly by major Product Lines)
5. Despatch/Delivery System (Possibly by major Product Lines)
6. Assets - Asset register
7. Finance (Receivables, Payables, Ledger)
8. Data Warehouse (One please)
9. Reporting - Customer, Management, Regulatory (Data Marts connected to Warehouse)
10. Reference - The single initiation point for Customer (Gold Copy)
11. Reference - External External market "temperature" prices, rates, indicators. (Gold Copy for company)
12. Reference - Other (Country, Currency, Legal Entity, Reporting Entity, Management Entity) (Gold copy)
This makes 6 Common Business Systems, 3 dependent on the number of Major Product Lines, and 3 Reference
Perfect number of databases = 9 + (3 * Major Product Lines). It doesn't look as impressive as E=Mc2 or anything like that, but simple is good.
We don't care that nobody (of any substantial size) will ever achieve that number since it is only a reference point, indeed I expect that the vast majority of companies will always exceed that number by a significant amount. What matters is that we have a reference point from which to test the health of companies Systems and their IT.
So, Megabank had around 11 major Business Products making their "perfect" Database number 42, which we all know is the answer to life, the universe and everything. They actually had around 2500 Applications each with a database, so that gives Megabank a database score of 2500/45 = 55.5. We're not going to get rid of 2444.5 databases, no way, - thats not the point. The point is that SuperBank (in the same industry) for the same number of major Business Products had 1500, making us look very inefficient since we are carrying enormous costs maintaining the extra 1000 databases and making ourselves less competetive.
And at this point I'm going to let this subject rest, since we'll all probably getting bored with it, but I would like to explore at some point how to address some of the problems of overdeployment, regardless of how it is measured!

Another Paradigm-shift?

noreply@blogger.com (CityArchitect) — Sat, 14 Mar 2009 23:07:00 +0000

The ever-increasing clock speeds of Processors seem to be coming to an end now; it seems we have come to the limit of the capabilities of our current technology. We had clock speeds of 2MHZ in the late 70s and early 80s, and have increased more than a thousand-fold to the GHZ clock speeds of today. But it does seem like we have reached a plateau at 4GHZ that we're having problems getting past.

The answer seems to be that instead of making processors go faster, we're actually just using more processors to solve our processing problems. So, we've moved from single processors to multiple processors (which really just increased the number of streams of work we could process) to the present mulitple core idea (which is just like multiple processor idea except we put the processors on one chip).

But are we really taking best advantage of these multiple-core processors? At some point, for personal computing at least, we don't have enough streams of work to take advantage, and the applications we use are constructed to support single streams of processing.

And I don't think the answer is just multi-threading programs like we've been doing for the last few years. Multi-threading is all about intimate knowledge of the work that needs processing and the mechanisms to allow it to happen safely.

I feel like we need here is another one of those paradigm-shifts of the kind that we engineered during the 90s with Object-Orientation (at least when OO came into the mainstream). We need to start thinking about little pieces of work, units of work applied to Objects perhaps. Something around the idea that all methods on Objects are naturally threads and then some mechanisms to synchronise the Objects readiness to interact?

While we are there, perhaps we can start viewing Grid as just an extention of Multi-Core, in that processors are either near or far away, the only difference is latency?

Anyway, in terms of my earlier blogs on What's the next language, I think that perhaps this might be a good direction..... I think we should name the next language "Q".....there! we're now well under way....

Are you leading or following?

noreply@blogger.com (CityArchitect) — Tue, 10 Mar 2009 23:06:00 +0000

A reader commented on an old blog of mine and the gist of his comment was around questioning why we change our technologies so much when it's patently clear that the old technologies provided good value.
When these new technologies are presented to us, they come packaged with all sort of promise about productivity, flexibility and cost-effectiveness but, I wonder, do we ever look back and assess whether they actually met their objectives? The short answer, of course, is no. We're all too bust looking ahead to the next technology step, and no-one looks back and analyses where we, perhaps, went wrong with the last one.
The reasons for this are probably numerous, but sometimes the most simple reason suffices here. - we're just too busy keeping up!
I've sensed this for a number of years, particularly around the development fraternity; the march of technology means that we're trying to stay current, keep up the pace, make sure our CVs are spot on the market. There's no money in philosophising, no demand for it, only a demand for technology solutions.
So, who's driving this? It's obvious we're all just too busy keeping up here, so it's not us.
It's the tools market, the products market. They need to stay in business, they need to keep you buying; and to do that they need to make the product attractive with new features. They invent the requirement for new technology; it doesn't exist without them.
The Internet is to blame too. It's all too easy to communicate now, it's all too easy to market ideas, it's all too easy to create the impression that there's a lot of activity around something which is essentially niche. And you fall for it hook, line and sinker! And your reaction propagates and re-enforces the message that there is a need, that this need is being met with the new Acme-Duffer widget set, and you need to get reading about it, training about it and using it!
Self-fulfilling prophesies.
When was the last time you lead the market for new technologies? Or are you just following?

Databases and ear discomfort

noreply@blogger.com (CityArchitect) — Sun, 01 Mar 2009 23:06:00 +0000

The train this morning was more crowded than usual, and in order for my mind to escape to a better place, I started musing on the database theme from my last blog, and at the same time imaging that I was doing the thinking from a sunny place on the beach, looking out over the ocean.
Problem was, I had a nagging feeling (similar to the laptop bag that my fellow commuter was sticking in my ear) that I hadn't got it quite right.
I got some really good comments on that last blog, but in particular I liked Venky Kurapati's around the idea that the number is related to the number of Business Processes that a company has, plus I'd reconsidered my orginal premise.....
Steveabram had concerns around having too complex a data model with too many tables, and I guess that Venky's one-per-process would satisfy Steve and push me further away from my one-size-fits-all database.
Let's backtrack, in practice all applications are built around a database, and those applications support a business process; then, Venky is on the right lines, but I'm a little worried that a single database here could and should support several similar business processes. So, although you need a database for the process, the optimum is less than one per process.
If you're going along the line of seperate databases per process, you're going to have to consolidate at some point in a Warehouse of some sort since your marketing People and your Financial people need their big picture of the business, so one more for the Warehouse.
I had considered having a seperate database for Company static information, structure and such like, but I decided that maintenance of that data was actually a business process (think account opening as a process) anyway, so it was probably already covered.
I still think we need a database to hold external data such a market information, including prices, rates. You need to capture it for a couple of reasons, (i) to keep it static for your business processes under changing market conditions, and (ii) it's more efficient than accessing the Internet 100 times a second when you need the data.
So, it seems that the answer is (number of business processes) + warehouse + external.
And as said before, this is the maximum since we expect you to more efficient with multiple processes accessing one database.
I'm actually going somewhere with this line, so stay tuned, or if you already get it now, then comment appropriately.....
Thanks for listening....

How many databases does it take to change a lightbulb?

noreply@blogger.com (CityArchitect) — Wed, 25 Feb 2009 23:05:00 +0000

I was on the train this morning alongside my fellow commuters when I had one of little thought moments (They're getting fewer and fewer as the years roll on!), as I was pondering the average companies database portfolio.
Database Portfolio? I guess you're saying "that's a new one on me..".
What I mean is that a typical large company probably has thousands of different databases, each having a different application use, or supplying a different view of the company's data assets.
Why so many? Well, lot's of reasons, many of them absolutely practical or pragmatic atttempts to deliver a particular piece of functionality to the business within the timescales given.
We keep on doing it, adding more and more, and someone out there's sweeping along behind, taking feeds from them all, transforming the data and creating new ones.
I think it's absolutely obvious to everyone that in Logical Terms there is only one database, one data model, actually required to run a business, but I don't think anyone ever gets there (yes, yes, I know the little start-up down the road only has one, but you know too that the little start-up is going to end up with a hundred in five years time).
So, I started to ask myself, that since we're never going to find the one database in a mature company, what is the smallest number of practical databases that are required to run a business, and that won't get in the way of the company's development?
By the time that my train had reached it's destination this morning, I had decided that the answer was THREE; one for the Company's structures, one for the Company's Products, Transactions and Customers, and one for anything external that the company relied on for taking the market temperature (prices, rates etc).
What's your take? Think of a mature company and give me an estimate of the number of databases OR, tell me how many databases if takes to run a company (or to change a lightbulb)?

Not all developers are born equal

noreply@blogger.com (CityArchitect) — Tue, 24 Feb 2009 23:04:00 +0000

Like all people new to this commercial world of Information Technology, he's got one of those wonderful pure views of how things should be. I, of course, took it upon myself to do my duty and make a few corrections to his rather rosy view............
One of the things that seems to have struck him first, is that not all developers are born equal. Yes, surprising isn't it? What is it that make some developers so well paid?
Well who's paid more? There's the older ones, experience always tells. Then there's the specialist ones, using perhaps, those wonderful niche technologies from the Middleware vendors I'm always sounding off about. There's the quick ones, yes, productivity is high on our shopping list. And then there's the ones that network well, maintain good relations with those around them, mainly bosses....And then there's the ones that are in the right place at the right time....And then there are those that write code in niche languages (I remember once meeting a guy who, five years ago, was earning $250k to provide support for some APL code that some of our traders were using to price financial instruments, and only worked on average 2 days per month!).
I'd like readers to help me here, and give my son a little advice on how to progress in his chosen profession. Please give him some pointers so that within a few years he'll have stopped going on about what everyone else earns........Responses please......Thanks!.....

Quality and Risk

noreply@blogger.com (CityArchitect) — Wed, 11 Feb 2009 21:56:00 +0000

In earlier blogs you may have spotted my keen interest in relating Architecture Qualities directly to implied Operational Risk in the solution. Well I think I'm getting closer…….
As you may have seen, I assert (although you probably don't need any convincing) that a deficiency in any aspect of my Integrity Qualities is going to result in a risk of some sort. These Integrity risks are always risks resulting in "Loss, Duplication or Corruption" of data and relate directly to Operational Risk. In fact if you consider it a little longer you will come to the conclusion that Integrity Risks against a Customer will actually result in Franchise Risk, or risks to the Business itself.
So all this seems obvious doesn't it? Well perhaps it's not that obvious since it didn't occur to me when I started out there with all the newest, hottest, unproved technology that was dying to be used, and it only started to really come home to me as I reviewed project after project using weak technologies and techniques. What I was doing when I advised them not to use technology like that, and not to use that particular technology, that what I was doing was going soft on the designers at the expense of the Business.
With that in mind I decided to try and formulate a reasoned approach to showing how Quality related directly to Risk, since without a good, well thought-out argument I wouldn't be getting far with these intelligent, switched-on developers.
Well, what kind of risk and what degree of risk arises when we breach Authorisation guidelines? The risk is obvious; it's a risk that someone can enter a system that is not supposed to, but how big a risk is it?
Standard Risk Management techniques dictate that you should:
1. Know what you are measuring risk for.
2. Identify the Risks.
3. Measure the Risks.
4. Manage the Risks.
Well point number 1 is covered since we know we are trying to provide direct measures between choice of technology or method and implied Operational Risk in the solution.
Identifying the risks is also OK since we do this by reviewing the Architecture for sub-standard solutions and design holes, and Managing is the mitigation of the risks by taking action in some way to improve the situation.
But, point number 3 is the hard one, what we say is "What is the Likelihood of it happening?" - we're looking for a measure of the chance of a particular thing happening, and as all good Mathematicians know, this is a value from 0 (no chance) to 1 (guaranteed). This is still a hard figure to identify, since you are going to have to do some research to figure out historically how many breaches of Security you had on this particular interface, or similar interfaces and, this is the another hard bit - you're going to have to work out what a breach in Security actually cost you in Dollars, or Pounds, or Euros or whatever.
That is the true measure of the risk - the money you lose, the cost to the Business itself. Now you can get some attention from your IT Management and their paymasters - go tell them, and while you're there tell them why they need to increase the Architecture budget this year, and of course, why they need to pay you more.
--
Posted By CityArchitect to CityArchitect on 3/30/2006 09:55:00 PM

Getting the requirements right

noreply@blogger.com (CityArchitect) — Tue, 10 Feb 2009 21:53:00 +0000

Right now I'm working on a fairly large complex project and we've only just started. Would you believe the number of people getting their hands dirty in the technical aspects? And we haven't done the Requirements yet!
You must have met this before, an exciting new project comes up and people all want to get involved and offer their advice and solutions. We're all techies at heart, we all revert to our roots no matter how long we've been away from them; we can't stop ourselves I guess.
The upshot of this is that we've already got some technical problems to deal with and we've got teams of people addressing them. The teams are working on , for instance, making the system more responsive. I can hear you saying "How fast are they trying to make it?" and the plain fact of the matter is that we don't know. All we do know is that we'd like it to be no slower than the old system, regardless of the fact that the old system is based on a different workflow model entirely.
How do we know that it has to be as fast as the old system? We don't. We need to ask and that's what gathering requirements is all about. Don't ask me, ask Tom Gilb (www.gilb.com), a renowned expert of Software Engineering, and he'll tell you about specifying the "non-functional" requirements of a system.
These are the kind of requirements that I've been referring to as my Architectural Qualities, and what I'm trying to do is to relate these requirements (Gilb-style) all the way down to measurements of the deployed system. Relate what you want, through what you Architecture for, through to what you build, and what you verify in the resultant system.
Anyway, the requirements phase is beginning real soon now, and perhaps then we'll be able to give all these techies something more determinant to work on!

Where’s the people?

noreply@blogger.com (CityArchitect) — Tue, 03 Feb 2009 21:53:00 +0000

We're doing Disaster Recovery planning or what's sometimes called Continuity of Business, which sounds a little less threatening. We've got extra Servers, we've got extra Software, we've got extra networks and we've got an extra shiny Data Centre to put it all in, but, where's this army of people needed to get it all going?
The thing is, we need to allocate people against all the Roles involved in Managing Applications, and all the roles involved in Managing Servers, and make sure that the people fulfilling these roles have Primaries and Secondaries. Oh, and by the way, make sure that Primaries and Secondaries reside on separate sites.
This all takes some measure of accounting, testing and quality control, so get busy with those spreadsheets! Oh, and by the way make sure that there are two copies of the spreadsheet, and each copy is accessible from separate sites and by separate routes through your network……….
It just like designing non-stop systems, eliminate the single point of failure, and make sure you include people, data, documents and access. All that's left in the end is one single point of failure, your single point of wages, your Company.

Measuring Architecture

noreply@blogger.com (CityArchitect) — Mon, 02 Feb 2009 21:51:00 +0000

A Software Architecture is essentially a structure and a set of quality statements about that structure. Oh yes, and some technologies…but the technologies aren't that important. No, really, what IS important is that the technologies chosen work together to meet business requirements given in terms of those qualities.
How does that work? Well, consider that your business may ask you to produce a system that is available between 9am and 6pm every weekday; that requirement is actually a quality under the general category of "Availability"; specifically I would put it under the sub-category of "Service Window". How well a particular architecture meets these criteria is a measure of its quality in this respect.
Let's try another; your business asks that specific functionality is only available to those people who entitled to use them. I would put this under the general category of "Confidentiality", sub-category "Authorisation".
You may recognise these Categories; they're the usual suspects - Confidentiality, Integrity and Availability. Others that you can name probably fit neatly under these as sub-categories.
I think that it is important to measure architectures in this way as an antidote, if you like, to the Technical "Architects" that wander round our corporate landscape praising J2EE or .Net as a great "architecture", when what they really mean is that they are cool technologies. Yes they've got structure and yes, they are nicely layered, and yes, they're open (well some of them), but that's about all you can say about them without stating how they match to the business requirements of that architecture. Sorry, that was a bit of a rant….
When we review architectures or indeed designs we always have our stock questions that we ask like "How Fast?" or "How Reliable?". Well I've got mine that I've built up over the last few years and I'd like to share them with you piece at a time. Let me know if you agree with them, let me know if you don't, and please, do let me know if I've missed anything. Stay tuned.

Bringing it all together

noreply@blogger.com (CityArchitect) — Thu, 22 Jan 2009 23:06:00 +0000

One of the things I've commented on in the past was around the subject of proliferation of databases and what the optimum number of databases that a typical organisation requires here . You'll guess, of course, that I am going towards the idea that there should be only one.
What would it be like to have only one?
It would be nirvana In data terms, since all the organisations data would be available in the one place.
It could be nirvana in informational terms since the opportunity would have been presented that would allow disparate data items to become connected in some way.
It would probably be a nightmare in complexity terms if all the possible connectivity had been implemented.
To see how much connectivity you would need, all you have to do is look around you, around your desk and office, and what you do in your daily life.
For example, the concept of you is probably encompassed in your HR systems and in your authentication systems; you'll need some form of connectivity there. Your desk is probably recorded in some furniture assets system somewhere; you'll need to be connected to that data as a user of the desk. Your phone needs connecting to your desk number, and your phone number needs connecting to you. Your PC is in the Asset Database, and the licenses on it are recorded somewhere else.
All the data is out there, in databases everywhere. What we don't have here is the means to bring it all together, and please don't say warehouse......
But I think we may be getting there, but the solutions may not be mature, I'd like to talk about one such method next.....

IT Strategy Part 5 - Pulling it all together

noreply@blogger.com (CityArchitect) — Tue, 13 Jan 2009 22:17:00 +0000

I've been blogging about this for the last two weeks; it's time we pulled it all together...
Our IT Strategy should be a cohesive all-encompassing plan, but because it may run for a long time, it must not be rigid. Long-running projects that were orginally Business-Aligned never end up that way. Our plan must allow for review and we will need to be able to adapt to changing Business Patterns and Market forces.
Structuring our IT Strategy in this way is fortunate, since Visions are less likely to change than Goals, which are equally less likely to change than our Objectives.
We manage our Objectives as Projects, and standard Project Management techniques are employed including prioritisation to ensure that the returns are going to be met in terms of any re-stated Goals, and also providing the ability to manage our resources effectively towards Objectives affording the best returns.
Strong Management of our IT Strategic program will keep us working towards our Goals, with our Vision in mind whilst maintaining adaptability in the face of changing conditions.
In terms of our Methodology, the initial steps in forming the Strategy is the working together to discover the Vision that characterises the Business, and the Goals that must be satisfied in order to be successful.
Often, much is known about Goals and IT Organisations already and, in addition, some specific problem areas. These problems will need to be re-stated in terms of the agreed Goals.
It will be necessary to obtain data to perform the initial cost model, and a survey of the existing infrastructure landscape. The best information and expertise available is almost always present with the existing people;it often needs a little re-direction to achieve the best leverage.
Voila, my methodology in a nutshell for formalating an IT Strategy. This doesn't tell you enough of course, there's much more work involved, but I'll leave you to find that out...

IT Strategy Part 4 - Be Objective

noreply@blogger.com (CityArchitect) — Thu, 08 Jan 2009 22:17:00 +0000

And onto Objectives, another installment of my Strategy Blog, now we're getting more detailed, driving deeper....
Objective - A specific point in a plan, a waypoint on our journey.
Our Objectives get more specific than our Goals (covered in the last Blog), in that they are more near-term and somewhat tactical. Objectives are the things we need to do to home us in on our Goals. Objectives require more ingenuity or skill, and are characterised in the actual tasks we carry out in pursuit of our Goals.
In terms of our IT Strategy, Objectives are embodied in our Projects, and Projects are the defined collections of work that we carry out. Projects are measured on the Return on Investment (ROI); the return measured in terms of our advancement towards our Goals. One Objective could be stated as "Server Consolidation" that offers a reduction in Data Centre Costs of 10% towards our Goal of 15%. In other words, each of our Objectives doesn't seek to achieve the whole Goal; Objectives are smaller, manageable packets of work that seek to move us closer and closer towards our Goal.
In IT Infrastructure, the most common Objectives are related to:
Reducing Total Cost of Ownership
Reducing Time to Market
Increasing Availability
Reducing Operational Risk
and are couched in terms of:
Scaleability
Confidentiality
Reliability
Versatility
Integration
Typical Objectives are embodied in Projects that perform "Server Consolidation", "Platform Management System", "Help Desk", "Cost Control", "Systems Inventory", and each Project must be characterised in terms of the stated Goals.
I'll try to pull this all together in the next blog....

IT Strategy Part 3 - Goals, Goals, Goals

noreply@blogger.com (CityArchitect) — Mon, 05 Jan 2009 22:16:00 +0000

Introducing the next part in my IT Strategy blog. We've looked at Strategy, and we've looked at Visions, now it's the time for Goals. So let the match begin...
Goals - The state of affairs that a plan is intended to achieve and that, when achieved, terminates behaviour intended to achieve it
In order for our Strategy to have any focus, and to give us something to aim for, we set ourselves Goals. Goals are something that we seek to reach, something to validate that we have achieved something.
All endevours must have an end-game, otherwise we don't know whether we have succeeded or not, we can't set out on an investment path without knowing what the return is. (Regular readers of my blogs will recognise the same Philosophy I apply to Qualities and Measurement - I resist doing anything that can't be measured).
Whereas our Vision may have been something fairly ethereal "To offer the highest quality, lowest cost IT Systems", our Goals get much more specific -
"Lower the cost of our Data Centres by 15%"
"Increase reliability of our Systems from 99.95% to 99.99%"
"Reduce staffing costs by 10%" (You've all heard that one before)
Goals are clear and measureable; we know when we've achieved them.
Hope you're following this, stay tuned for more...

Strategy, Vision, Goal, Objective

noreply@blogger.com (CityArchitect) — Sat, 03 Jan 2009 23:05:00 +0000

I blogged around this some time ago, but someone asked me the question again, so I thought I'd repeat myself a little. What is a Strategy? Well, without a structure and a plan, it's not very much at all.
Strategy - "An elaborate and systematic plan of action"
The definition implies there is much more to it than just someone standing up and declaring our Strategy to be "Move to Linux". You can see straight away that just making a declaration isn't exactly elaborate let alone a plan of action; no, you have to back it up with some structure.
OK, let's try another one. What is a Vision?
Vision - "The power of imagination"
It's right out there at the start; you have to imagine what your future world is going to look like, think out of the box, brainstorm, whatever. Think about how you would like your world to be and record it. Visions are the "mission statements" of your Strategy. A Vision could be "Imagine all of our infrastructure was based on Linux"
Keep going now...... What is a Goal?
Goal - "The state of affairs that a plan is intended to achieve and that, when achieved, terminates behaviour intended to achieve it"
Wow, this is getting better now. Where do Goals fit in? Well, we set our Goals to align with our Vision. Staying with our Vision, we decide that possible Goals could be "Train all personel in Linux" or "Find Linux solutions for all our Middleware needs". Set clear Goals within your Vision and record them. Goals are milestones, significant events towards the Vision.
Right, one last one, What is an Objective?
Objective - "A specific point in a plan, a waypoint on our journey"
Objectives are a bit more specific than Goals, they are more near-term, and perhaps tactical. Objectives are specific, require skill, and are characterised in the actual tasks we carry out in pursuit of our goals.
In our grand IT Strategy, we make sure that Objectives are being met in our projects (check in reviews), perhaps even measure how far the Objectives are being met, to what percentage, so that we record progress towards our Goals.
Our IT Strategy should be a cohesive, all-encompassing plan and, because it may run for a very long time, we have to make sure that it's not too rigid. Long-running projects that were orginally Business-Aligned never end up that way. Our Strategy must allow for review so as to allow for changing business patterns and market forces.
So, the IT Strategy is composed of some Visions, each of which have Goals, each of which have Objectives. This structure is good, since Visions are less likely to change than Goals, which are equally less likely to change than our Objectives.
Every time you carry out or take part in a project, ask yourself "Does this align with our Strategy?", and see if anyone offers you documented statements and metrics to back it up.

IT Strategy - Part 2 (Vision or Mirage?)

noreply@blogger.com (CityArchitect) — Sat, 03 Jan 2009 22:16:00 +0000

This is part 2 in my IT Strategy blog, I know you've been out there hanging on tenterhooks (where did that come from?). This time I'd like to ask the question "Do you have Vision?"...
Again, a definition:
"Vision" ' the power of imagination
Last time I talked in general about strategy itself, this time we need to start thinking about what we are trying to achieve, a vision for the future of the IT Systems under your remit. This vision is an amalgam of Business needs, market demands, technology trends, regulatory pressures, and some other stuff.
In striving to be "Business-driven" or "Business-aligned", we are trying to match what the business does, or wants to do, with qualities and functionality in our IT Systems. Or to put it simply:
If the Business is a low-cost airline carrier, then the IT Systems probably need to be low-cost, customer-facing and customer-driven, and Internet.
If the Business is in Bank Clearing, then the IT Systems probably need to be High-Quality, continuously available, Bank-facing and use private, high-security communications in a regulated, auditable environment.
If the Business is known for Innovation in the Financial Markets, then the IT Systems probably need to be engineered to be highly flexible with low delivery times producing lower time-to-market.
And, in the light of the state of todays world, if we don't engineer our IT Systems and locations to be able to support Continuity of Business, there's just a chance the Business won't exist tomorrow.
As well as knowing the current business needs, you might just want to consult with your CEO to look at where the Business is going, without this strong linkage between Business Drivers and IT Systems planning, the Business won't be going anywhere!
These "themes" constitute the Visions statement for the IT Strategy; the general guidelines that keep us Business-Aligned and become the Mission Statement upon which we base our Goals. (coming next)

IT Strategy – Part 1 (So you think you have a strategy huh?)

noreply@blogger.com (CityArchitect) — Fri, 02 Jan 2009 22:16:00 +0000

I'm going to leave the subject of Architecture Qualities for a while to turn instead to something all Technologists ought to be aquainted with - Strategy.
We all think we have a strategy, even if it's only the route down to the mall tomorrow...
OK, a definition first.
"Strategy" - An elaborate and systematic plan of action
A Strategy is a plan, a roadmap along which IT Projects run in a defined path towards a defined goal. Without strategy we continually work in reaction mode, changing plans and resources as we go, neither generally advancing towards nor retreating from business ideals, in effect, we constantly strive to remain in the current state.
The problem with this state of affairs is that Technology doesn't stand still; our Businesses demand new functionality and adaptations of existing functionality to change with market conditions.
What happens if we don't have it? Some examples:
Our Business as Usual costs go up, whilst or budgets stay the same or decrease; we starve ourselves of investment money.
Our infrastructure expands out-of-control, filing up our Data Centres with more and more increasingly outdated equipment, with ever-increasing demands on power and cooling.
The number of people employed to manage the infrastructure spirals out of control, increasing demands on costs and office space.
You have probably already recognised something in your own organisations here, but don't worry I think the problem may be widespread!
You see, the pace of technology, and indeed the price of technology, makes us work without really thinking. We don't think about the cost of the boxes, because we know they're kind of cheap-ish and in any case we know the very real risks in trying to share boxes between applications (Change Risks). So we let these boxes build up until some bright spark invents Server Consolidation; working in reaction mode again, not to a Strategy (of course you could say that getting in a mess and then having the occasional tidy up IS your strategy).
More in Part 2...

Offshoring and Quality

noreply@blogger.com (CityArchitect) — Tue, 18 Nov 2008 23:04:00 +0000

I'd like to put the record straight here, because I may have given the impression with my last blog that somehow I was getting better Quality just because I had lower Costs from offshoring IT effort.
Quality is only indentifiably improved (i.e. you can prove it) when you have processes that support the required Quality steps, and Quality is only improved when you care.
So, what am I saying here? Well, what's the point of having the best quality in the world if no-one knows about it (i.e. they can measure it); they'll only go changing things about again and make things worse. Having a process and metrics for measuring your progress is the only sensible approach.
Problem is here that in order to carry out the processes you need dedicated resource, more people, and people don't come cheap. That's why I am hopeful that by spending the same amount of money offshore as I do onshore, I'm getting more people to carry out the same job with all the necessary Quality and IT Control processes.
Simple isn't it? I know it doesn't get me true Quality, since quality is more elusive than that. But at least it gives me measurement so that I know whether I've got Quality, getting Quality, or lost Quality.
The final piece in the jigsaw comes when we have Quality people; and I'm afraid this is the difficult one because to do that you need people who care, and people who don't work for your company care little about your company, they work solely towards the figures, the metrics, that you've so carefully put in place.......

Silicon is coming, watch out Grid!

noreply@blogger.com (CityArchitect) — Fri, 14 Nov 2008 23:03:00 +0000

Grid Computing is one of those technology areas that I'm not comfortable with. The concept of harnessing the power 100,000 machines together for a specific calculation purpose (e.g. SETI), I can understand. The concept of harnessing 100s or even 1000s of your own machines in your company in order to get consolidated compute power bothers me.
As I've said before silicon overtakes software sooner or later and in the case of grid we all know that speed is one of those attributes that is ever moving. So, processor speeds are still climbing and our super hardware engineers have found ways of putting multiple cores on a single chip; with a little more density, better processor scheduling, a little more speed, and a few more cores we will quickly be processing at 100 times our present speeds.
If you're doing Credit or Market Risk computations, surely this fills the gap? Otherwise if it's offline long-running processing for a few hours in the day perhaps, isn't this just a matter of scheduling ownership of the (same?) compute facility in that new blade server sometime overnight after the batch run has finished?
IBM's on-demand philosophy could also fit in here, why not buy compute power just when you need it (and at the cheapest time?).
Surely a managed environment is better for your business's processing rather than trawling the corporate desktop landscape? If you need it right now, and you don't have to invest much effort, then OK use it. But be prepared to move your code quickly off it when the alternative pops up.
So for me, Grid is OK now; it's even cool, but the writing is on the wall, silicon's coming.......
Come on, that must have got you going......Challenges please...

You can't beat silicon...

noreply@blogger.com (CityArchitect) — Wed, 12 Nov 2008 23:03:00 +0000

One of the things I really like to do is watch the Software Product space and how the Software industry finds ways of earning their meagre crust, and I'm often surprised at the way that some products make it big and some products don't.
Often, success turns on the product being there at the right time, and it's an aspect of what the right time is that has captured my attention today....
What is the right time for a software product? Well, often it's because of Hardware inadequacy, particularly in the performance space.
Many years ago I specialised in Mainframe System Performance (I won't tell you which mainframe to save me from embarrassment), spending much of my time benchmarking, collecting statistics, modelling and extrapolating performance etc. We did it because processor time or I/O time was expensive and upgrades were always major.
Software vendors sprung up into the space, automatically monitoring and tuning system parameters (of which there were an enormous number) to get the best performance from your machine. They were there at the right time, they got the revenue, they floated and got the cash, and the shareholders were left with the company. Trouble was, the shareholders often bought based on the start-up revenue stream, which of course depended highly on the opportunity window in the marketplace which had a habit of closing suddenly.
By far the most common closing of those opportunities was because hardware had advanced, processors and I/O got many times faster, Disk Storage got much denser and cheaper. The root cause of the opportunity disappears, the problem becomes less and less significant.
Try these:
Disk compression technologies, Run-Length Encoding - Closed.
Anything that saved 20% of your mainframe processor cycles - Closed.
Virtual Memory Systems? - Closing?
Bottom line is, that you can't beat silicon. It will always overtake software products in the end, and I'm going to give you a few more examples over the next few blogs.
But, as always, you know which software technologies that are in an opportunity window right now, soon to be closed, why not let our readers know? Comments, as always, are very much welcomed.
By the way, no comments about whether it's silicon, gallium arsenide or whatever, you know what I mean......

Development - Art or Science (again!)

noreply@blogger.com (CityArchitect) — Sat, 08 Nov 2008 23:02:00 +0000

I was reading an article on Martin Fowler's site today. It was centred around some issues of Agile Development and how we got there, and in reading it, I started to revisit the old question of whether Programming is an art or a science.
Now, of course, you have your own ideas on this, and I encourage you to share them with our readers; this is one of those highly debatable areas, and if there's one thing that I've learnt in this life is that nothing is true, nothing is certain and everything is subjective.
What were we trying to do when we invented System Development Lifecycles? Well, we were trying to put some form, some method, around development of systems so that they could become more predictable and that Intellectual Assets could be recorded in a prescriptive way. In short, we were mechanising the development of systems, turning it into an engineering task.
Development, or programming is an engineering discipline when done within a SDLC. It has to be, there is no way around it if you want the outcome to have any kind of certainty. Done this way, it's a science.
Art is a very different thing; for the most part the outcome is not required to be a certainty, indeed to have any value at all, the outcome should be unique and non-predictable. You will realise that I'm not talking about people who do portraits or those that do characatures of you at the seaside here, I'm talking about those that look at an empty canvas and start splashing paint around, not knowing where it will lead them.
You will notice that no-ones gone out of their way to produce a Artistic Development Lifecycle (ADLC) for painters here, they've given them free rein, left them to their own devices, and waited for a totally unique outcome; valuing the outcome based on its unique merits.
Is there a case, a situation, where you would leave developers to their own devices? Well, I guess that many of the great advances of today's technology
have actually come from artistic developers who didn't know the outcome when they started out; they played, they tried things, until they produced something that was valued (or not) based on it's own individual, unique merits.
So, do we have room for both kinds of developers, both scientists and artists, in this world of ours? Of course we do, each have their own place, their own value.
Is their any kind of methodology that can be applied to artistic development, so that we can get any certainty of outcome? Probably not. Which make funding of Research and Development costly and risky, best left to those with deep pockets, or $7B war chests........