The corporate IT balancing act: agility vs. stability

By |2006-08-13T18:29:00+00:00August 13th, 2006|Enterprise Architecture|

You are the CIO.  You have a choice.

On one end of the spectrum, you can control costs by delivering a centrally architected set of solutions, probably on one platform (like Oracle or SAP), and make the businesses change to the out-of-the-box processes.  Your IT costs can come under control, but your business change costs will be through the roof, and you will get ‘commodity’ transaction handling.  Forget about IT being a strategic partner. 

On the other end, you can empower the business by allowing the business to buy any solution they want, and you just roll it into production and keep it running.  The business can roll out a new idea or a new program as quickly as they can buy technology.  Sure, you can write some things, but you are just one vendor out of many.  You don’t even try to integrate things until the data hits the data warehouse, where you attempt to cobble something together.  Programs roll out fast, but business intelligence suffers, the number of applications grow geometrically, and the overall cost of IT grows uncontrollably.

Many of you, dear readers, will recognize your current environment in one of these extremes.  If you do, send an anonymous letter to your board of directors and point them here.  I’ll say the obvious: your CIO is a moron and should be fired.

Somewhere in the middle is the right answer. 

Business needs agility to survive in a competitive marketplace.  Business is not served by cost controls that hinder creativity.  In addition, IT can only be a strategic partner if it is not hamstrung by its own red tape and cost controls.  If you are in the centrally controlled model, you need to lighten up, find common ground and make a new relationship between the business and IT. 

On the other hand, rolling out hundreds of solutions when a dozen will do means that the business cannot get good business intelligence about your customers, partners, suppliers, and business trends.  That puts your company at a competitive disadvantage, especially over new competitors who may be smaller, more tightly focused, and eating away at your biggest profit center.  If this is you, you need to focus on key platforms, cut off investments gone wild, establish muscular governance and enterprise architecture, and reorganize IT around core business capabilities, instead of business functions.

It is a balance.  You have to allow freedom, especially in the areas where freedom can be the difference between a big profit and struggling to get by.  You also have to be efficient, and find ways to keep the wild-eyed marketing ideas from sucking your budget dry. 

Right-sizing IT is possible.  With the paradigm of solution domains and Service-Oriented IT, it can be done.  I will be discussing many of these ideas on this blog and in my upcoming book over the course of the coming year. 

Know this.  Sticking to one extreme or another is turning IT into a liability instead of an asset.

Third attempt – definition of an application in a SOA environment

By |2006-08-11T20:07:00+00:00August 11th, 2006|Enterprise Architecture|

In a previous post, I rattled on about the problems faced by Application Portfolio managers who wish to reduce the total cost of ownership and measure portfolio return through the oversimplified lens of “how many apps do you have?”

I complained, rather heartily, that the older definitions of an app are no longer valid.  However, I didn’t propose a new definition.  Bad Nick.  OK… third try.

First, what is the purpose of the definition?  To whom does it apply?

This definition is useful only for counting the NUMBER of applications in your portfolio and for determining the boundaries of that application.  Why would you want to know the boundaries of an application?  Because, in the world of composite applications, the boundaries allow you to measure the complexity of the app once and only once.  This allows the basic formula to be: Complexity of portfolio = sum of (complexity of application)

Therefore, I would define an application in the following manner:

Application – An executable software component or tightly coupled set of executable software components (one or more) that deliver some or all of a series of steps needed to create, update, manage, calculate or display information for a specific business purpose.  In order to be counted, each component must not be a member of another application. 

Of course, my definition of ‘application’ included a reference to the term ‘software component’ so I need to define that too.

Software Component – An executable set of computer instructions contained in a single deployment container in such a way that it cannot be broken apart further.  Examples include a Dynamic Link Library, an ASP web page, and a command line EXE app.  A zip file may contain zero or more software components because it is easy to break them down further (by unpacking the ZIP archive).

By this definition, the following ‘things’ are applications:

  • A web service endpoint that presents three web services: InvoiceCreate, InvoiceSearch, and InvoiceDetailGet
  • A service oriented business application (SOBA) that presents a user interface for creating invoices, and that turns around and calls the InvoiceCreate service.  (note that the service itself is a different application).
  • A legacy system composed of a rich client, a server-based middle tier, and a database, all of which are tightly coupled. (e.g. changes in one are very likely to trigger changes in another).
  • A web site publishing system that pulls data from a database and publishes it to an HTML format as a sub-site on a public URL.
  • A database that presents data to an Excel workbook that queries the information for layout and calculations.  This is interesting in that the database itself is an application unless the database is already included in another application (like a legacy system). 
  • An Excel spreadsheet that contains a coherent set of reusable macros that deliver business value.  The spreadsheet itself constitutes a deployment container for the application (like a TAR or CAB file). 
  • A set of ASP or PHP web pages that work in conjunction with one another to deliver the experience and logic of a web application.  It is entirely possible that a subsite would qualify as a seperate application under this definition if the coupling is loose.
  • A web service that no one uses, but which can be rationally understood to represent one or more useful steps in a business process.

The following thngs are not an application at all

  • An HTML web site.
  • A database that contains data but is not part of any series of steps to deliver business value using that data. 
  • A web service that is structurally incapable of being part of a set of steps that provides value.  For example, if you create a web service, but you require that the data that arrives can only be useful by the app if it breaks the web service schema, then you have not deployed an app.  You have deployed trash. 

The following things are many applications

  • A composite SOA application where you develop a set of reusable services and a user interface that leverages those services.  Note that you do not count each service as an app.  Depending on how many tightly coupled components you built, you may have a single servicies endpoint that presents many services, or you may have a couple of service endpoints that are independent from one another.  It is the amount of coupling that defines the application, and therefore it’s boundary.
  • A legacy client-server app that writes to a database to store data, and an excel spreadsheet that uses macros to read data from the database to present a report.  There are TWO apps in this example.  The database clearly belongs to the legacy app in that was developed with it, delivered with it, and is tightly coupled to it.  This is true even if the legacy system uses the same stored procedures as the Excel spreadsheet.

Agreement, Consensus, Unity and other fables

By |2006-08-08T10:05:00+00:00August 8th, 2006|Enterprise Architecture|

I blame it on Jacob. 

There are many project managers in the company, but Jacob is just plain different.  Take Tom for example.  When he needs to kick off a project, its pretty straight forward.

“The requirements have been signed off.  You can find them on the team Sharepoint site.  Let’s start walking through them on Tuesday and get tasks and estimates in the project plan.  I have a templat plan right here.  We will be using the standard development proces…”

Very tactical.  Specific.  As a developer, it’s what I’m used to.  But when Jacob called me to a meeting last week, it was just plain odd.

“We are here to create a distributed system design that allows a new sales program to be inserted and then changed over time.  We are the decision body, but other teams will actually design the components, build, test, and deploy.  We are where escalation comes to first.  So we need to agree on our mission, our strategies, our tactics and our guiding principles.”

I’m not kidding!  Guiding Principles!  I was amazed.  There were 10 other people, all senior, sitting around the table from different development groups in the company.  Our departments had never worked together before, but we knew how to write code and deploy it.  What the heck was he talking about!

So we went through the strawman mission statement and added things to the principles.  I pulled up the statement of principles that my management team sent around a couple of weeks before and added it in.  Jacob asked me to read them to the group and discuss the points that mattered to me personally.  He edited the text right into his team notes and had me approve his edits.  It was all very detailed.

But did it have anything to do with design?  I mean, really.  Ten people.  Four Hours.  That’s forty hours of work for senior people.  What did we get for it?  Three pages of notes, a short list of a few consensus decisions, and a list of open concerns that need to be escalated to management.  And there are more of these meetings to come.  I think we wasted time.

What a fool.  We could have actually done the design in forty hours!  Then we can simply tell our teams what the design should look like, and they will do the work.  Simple.  The dev teams have no reason not to listen to us.  Like I said: Ten senior people, all technical.  Half had the word Architect in their title.

We didn’t have many disagreements.  We went through the whole afternoon, describing our view of how we were planning to use the accounting system, what patterns we wanted to use in messaging, and what ‘attributes’ our designs had to favor (like the ability to change business logic quickly, whether it was through data driven decisions, OO designs, or easily disposable interfaces).  We all shared in our viewpoints and we didn’t have much to disagree about.

Oh, there was that one point when we had to discuss the interfaces and whether we were developing one ‘really flexible’ interface app, or many ‘disposable’ interface apps, all using the services layer.  We talking about that one for forty-five minutes.  One group wanted to be able to put up an app quickly, and replace it quickly, by discarding little apps and replacing them with others.  Workflows, they called them. 

The other team wanted to build a data-driven app that would get display and interface rules from the database, and would leverage Windows Workflow Foundation for the collaboration and workflow. 

Jacob let each team present their vision.  Then he asked,

“What is the principle that you are choosing with this design?”  It was an odd question. 

The first group said “We need to change business interfaces quickly.  They change a lot with our customers and they are frustrated with the pace of change in the past. It needs to go from a new idea in a sales persons’ head to deployed code in three months.”

The other team thought about that for a minute.  We all wanted the same thing.  We all wanted our designs to be agile, rapid, maintainable, flexible.  We had discussed this, like, an hour before.

The consensus decision was “We will build our services layer to support the creation of multiple independent interfaces.  We will build our interface system to be dynamic and drive business rules from data.  However, if a business should find that our interface system is not able to meet their needs, they are free to create another interface, using what they can of our libraries, controls, and portal, as long as it sits on the same services layer.”

Jacob seemed happy with the decision.  He wrote it on the whiteboard and our note-taker entered it into the meeting notes.  That made it “official.”  I guess he got what he wanted.  I just don’t see why that was hard…

Corporate personal bad habits

By |2006-08-06T18:49:00+00:00August 6th, 2006|Enterprise Architecture|

We talk about corporate culture and how the ‘way’ the company does things affects how readily they change or adapt.  Is corporate culture all that different from personal habits, just on an institutional level?

Isn’t the problem of creating bad data, and then repeatedly cleaning it up pretty much the same as making a waiting for the pizza boxes to pile up before cleaning up the living room?

What about leaving the cap off the toothpaste?  Isn’t that the same as ignoring the fact that a good customer is mad at you, letting them shop around, and leave?  You have to spend up money because you ignored good practices and let the resource dry up.

What about failing to change the oil until your engine overheats?  Isn’t that the same as letting your facilities decay or maintenance fall off until you have a turnover problem in your staff?

So what are the IT specific versions of bad personal habits?

From an IT standpoint, you could say that failing to change your oil means the same as installing an app but choosing not to install service packs, security releases, or upgrades.

You could say that leaving the toilet seat up (it’s a guy thing) is similar to the sales side of the business ignoring the support side of the business when rolling out a program.  From an IT standpoint, it may be like the new development team ignoring the data management and app support team needs by delivering software that is difficult to install, lacking in documentation, or makes life difficult when diagnosing issues.

So what other personal habits, good or bad, would you consider to be equivalent to bad behavior in IT?

If your app uses MSDE and you want it to run on Vista… UPGRADE to SQL Server Express

By |2006-08-03T13:33:00+00:00August 3rd, 2006|Enterprise Architecture|

I’m sure you will hear this many times in the coming days.  If you are a software developer writing code for internal use or resale, and you are using MSDE as your database engine, it is time to upgrade.

SQL Server 2005 Express Edition is the newer version of MSDE and has many advantages.  You get a management tool, reporting services, and a larger database size among other things.  It is not difficult to upgrade. 

MSDE is not dead.  MS will continue to support it for a little while longer… just not on new versions of the OS.  So if your users are staying on XP Pro, you are fine, in a way.  Someday, your users will call up Dell or HP and order a PC, and it will have Vista on it.  Why wait?

Check it out. Benefits of Upgrading MSDE to SQL Server 2005 Express Edition

[update 8/5/06]  Alas, I find that I am not the correct person to be sharing this kind of news.  I was rather expecting this news to be posted in more places, so that I could add a long list of links at this time.  I can share a long list of other blog sites that have discussed the issue.  There is a Microsoft blog that has attempted to create a better impression, so I’ll add a link to Eric Nelson’s blog.  If you’d like more information on the decision not to extend support for MSDE to the Vista operating system, please start there. 

One further note: MSDE does run on Vista.  However, there is no support for it and new installations will not be legally OK after 2007.   Personally, asking a software vendor who has been shipping a seven-year-old free database engine to move up to one that is 100% compatible, better, faster, and easier to install, includes tools that the original one was missing, and is also free is not asking that much.  The biggest hit will be on corporations who spent money writing apps on MSDE.  

The art of listening

By |2006-08-03T01:44:00+00:00August 3rd, 2006|Enterprise Architecture|

Do you know how to listen?  I think I do.  I put down my preconceptions about what is right or fair, and I open up to another person’s point of view.  I listen not only to their words, but their context.  I repeat what I hear to make sure that I’m getting it.  It’s a skill, and as an EA, its darn useful.

Not everyone knows how or when to listen.  Sometimes I forget to listen, too.  It is the most unpleasent experience when I am called upon to observe but have forgotten to listen, because I cannot.  I must either check out and ignore the conversation, or butt in and dominate it.  I have done this at times, and it is frustrating for me, and for everyone else in the room.  I look back on the times when I could not listen and I am not proud of them.

How do I know when I am not listening?  Honestly?  It’s when I am talking.


Be careful of the 'stack' diagram

By |2006-08-02T10:15:00+00:00August 2nd, 2006|Enterprise Architecture|

I’m always a little leery of a stack diagram that shows ‘systems’ living at some level of the stack.  For example, a diagram that shows a series of different application user interfaces at the U/I layer, and then workflow services somewhere further down the stack. 

What makes me leery is the fiction of the diagram.  Yes, workflow services are called by the business layer of an application, and we want to make it clear where that integration lies.  But a workflow system has a user interface, middleware, and database.  It is an application in its own right, and if we were looking at a diagram of the workflow system, we’d see components living at every level of the stack.

Therefore, while the Integration to a workflow system may live at a particular level of the stack, the workflow system  itself is not at that level of the diagram.   

I guess I’m just a little cautious of these diagrams.  I’m supposed to be communicating to developers and other folks.  How well am I communicating if it isn’t clear that the service interface is simply an integration end point?

SQL Server has the same issues yet I don’t mind that one.  Not sure why.  Perhaps I’m just not used to seeing systems that don’t provide an entire layer. 

Your opinion?