Wednesday, September 15, 2010

New IT Initiative and the People Metrics

Even if a new and big IT initiative is not revolutionary, at least it is often a big leap forward. This must be a real cliché to state that humans are at the heart of any human endeavors. It looks more obvious when going through significant changes, which could sometimes lay huge burden on its people.

After summarizing my own experience of architecting IT initiatives, I have developed the following pretty straightforward metrics to put the people issue in a structured fashion from one perspective, and hope it can provoke IT leaders to solve people challenges more systemically and methodically.

AgreeableCapable/MarketableKnowledgeable
1 YYY
2 YYN
3 YNN
4 NNN
5 NYY
6 NNY
7 YNY
8 NYN


Agreeable: your people (employees and contractors) agree to your vision and the new initiative. They want to work with the rest of the team to move forward.

Capable/Marketable: they have the right skill sets, mindset and experience to make the vision and the new initiative to happen. More often than not, people who are capable are also marketable, which explains why I put them together.

Knowledgeable: they are SMEs and/or domain experts of your existing systems and/or business.

There will be 8 combinations of the above.

People in row 1 are those whom you should cherish the most. You should trust them, empower them and rely on them. If they are being scattered in multiple existing teams and being drowned, you should consider taking them out to form a core team or COE of your new initiative, which will utilize their full potentials to influence the rest.

People in row 2 are usually new consultants or new hires. You should figure out the fastest way possible to onboard them systemically and encourage the people in row 1 to mentor them. So they can apply their know-how to your specific situations.

People in row 3 are those whom you should train and coach, and make them become valuable players.

People in row 4 are those you might need to work the hardest to not allow it to happen that they might feel threatened by the new vision and the new initiative, and slow the new initiative down.

People in row 5 are those you should unite and spend extra effort to make them move to row 1.

People in row 6 are those whom you need to figure out ways to utilize their knowledge to help the new vision and new initiative.

People in row 7 are often long time employees whose have lagged behind the new things due to some reasons. You should re-equip them.

People in row 8 are probably the hardest to decide. Depending how much energy and time you have left after helping people in row 3 and 5, you might be able to figure out the right ways.

A leader should also conduct some statistical analysis. Even simple ones will be very helpful. You can summarize the total number of people from both vertical and horizontal views and build distribution curves using these numbers. There must be gaps between your desired curves and the current curves. For instance, in most of large companies with long history, the number of people who are in “knowledgeable” category usually are very high due to the simple fact that these companies have longer stretch to use IT and as a result, have more legacy systems to maintain and support. If the new initiative is to use newer technologies to create new systems that will replace the legacy systems, people in this category may not have the adequate skills and experience. And yet, their domain and existing system knowledge will be imperative to the new initiative.

By examining these two curves, you will need to come out a plan to methodically shift the current curve to the desired curve. Needless to say, this is not an easy task but is among the most essential excise if you want the new initiative to succeed.

Wednesday, August 25, 2010

From Business Building Blocks to Software Building Blocks

Business Building Blocks Software Building Blocks
Business Vocabulary Business Vocabulary Management and Repository
Business DataMetadata, DBMS, MDM, Data Quality, Data Integration
Business DomainDomain Driven, Domain-specific Industry Standards (ACORD, IAA, REA, IFX, etc.)
Business InformationBusiness Intelligence and Reporting
Business ContentContent Management, File Management
Business RuleBusiness Rule Management
Business ProcessBusiness Process Management, Business Activity Monitoring
Business EventBusiness Event Management, Complex Event Processing
Business ServiceSOA
Business ExperienceUser Experience, Unified User Communication Channels
Business SecurityIdentity Management


This simple matrix that is inspired by the Zachman Enterprise Framework is extremely important to Enterprise Custom Application Software (ECAS). It re-shapes the way how ECAS has been done, including but is not limited to:

1. how to align with business stakeholders
2. how to build core competencies
3. how to allocate the resources and skills, and form the design and development teams
4. how to organize the business requirement document, and organize and build the Business Architecture Repository
5. how to conduct the project – SDLC methodology
6. how to form the mindset and work habit as a true ECAS professional
7. Where to start a project and steps to move forward
8. how to organize the code base

I will put more detailed entries in the future about this.

Saturday, August 14, 2010

Six Sins of Conducting IT Project

1. No KPIs for objectively assessing success or failure of a project, all based on impressions and who says what about the project

2. No standard and guidelines about reviewing a project from technical, project and business views after the project implementation

3. No systemic aggregations and communications of lessons learned; no conscientious actions taken to avoid the previous lessons

4. No accountabilities for project struggles and failures; No reward/reorganization or punishment for project success or failure

5. No culture and behavior for project excellence: the sense that “I have something to deliver” is not enough

6. No actions taken on "the right people in the right place", just paying the lip service of it

Tuesday, July 13, 2010

Why Server Appliances Are Valid

I would like to argue a valid option (NOT the only option) to build appliances based upon their intended functionalities. All the key software will be installed into the appliance.

We can build an Operational/Transitional Appliance, which can contain application server (such as WebSphere Application Server, JBoss, IIS/.NET Framework), database (such as Oracle, SQLServer) and BPM server (such as WebSphere Process Server, jBPM, BizTalk Server), Business Rule Management server (IBM ILog JRules, JBoss Rule, BizTalk BRE), Data Service server (PowerCenter, SQL Server Integration Services, Talend) and others in one physical box.

We can build BI/Analytical Appliance, which can contain BI server (BusinessObjects, Jasper), database (such as Oracle, SQLServer), Business Rule Management server (IBM ILog JRules, JBoss Rule, BizTalk BRE), Data Service server (PowerCenter, SQL Server Integration Services, Talend) and others in one physical box.

This appliance can also be used to run big batch job with the following added into the mix: Job/Workload Management server (CA Autosys, Quartz Job Scheduler) and large volume data facilitator (PowerCenter Partitioning Option. SSIS Pipeline, Talend MPx).

Yes, there a lot of things going on within this one box. But there are definitely several advantages: a). it is much easier to manage; b). due the eliminated network latency, in some cases, it might perform better than putting each software server category into their own boxes – a popular topology during last decade; c) we can still have load-balancing and failover for the appliance; d) we can isolate the software servers using virtualization, which will increase fault tolerance and capacity allocations; e). if something goes wrong beyond repairing, simply throw the appliance away and put another one in; f) last but not least, it helps break the barriers among operational/transactional, BI/analytical and batch by sharing the metadata and business rules.

Wednesday, July 7, 2010

My Architecture Practices

  • Setting up the right boundaries and govern them are among the most important architecture works. Here is how I set the boundaries: organize the code that is based upon Data Service, Business Domain Service, Business Rule Service, Business Process Service, Integration Service, Security Service, Presentation Channel Service, and Common Technical Service, NOT, again NOT, based upon projects. It is forbidden to put project names in packages, classes, and codebase folders.
  • Establish the core: Business Architecture, Data Architecture and Solution Architecture – technical; delivery and vendor management – administrative; explore the rest
  • Business Architecture belongs to the business, dotted line to IT. Work with business people on daily basis, not project basis
  • Throw away the word document; it is evil. Use Enterprise Social software to create architecture repositories and facilitate knowledge accumulation and knowledge sharing
  • Break the barriers among transactional, operational, analytical, and batch applications. Data Service Hub and metadata hold the key to make it happen.
  • Emphasize the creation of foundations: business vocabulary and metadata
  • Establish the Center of Excellence: every project goes here and is filtered by it and governed by it, NO exception
  • Big picture guided Agile: Big Pig Agile Methodology
  • Two work stream: project and sideline. Change the budget and funding structure to support sideline work stream
  • Evaluate project based upon: efficiency, effectiveness, predictability, and consistency. Not just finish the project. Have third party evaluate the project objectively.
  • Separate the code base of quick and dirty projects from long shelf life projects
  • From technical sequencing perspective, make sure that Data Integration/MDM and security/identity management architectures are on the solid ground, before starting tackling integrations such as SOA (although SOA as a whole is beyond just architecture) and Portal

Funny Project Stories - part 1

When somebody promotes better ways of doing things, some people in project often ask, “why this one? why right now?”

“Time to market” is the most used excuse – “we have something to deliver”; the other one is “we are so unique that the new ways don’t apply here”.

The answer is simple, “If we don’t start somewhere, we will end up in nowhere.” because the following situations will surely happen:
1. “a penny wise but a dollar foolish”;
2. “Yesterday's solutions are today's problems”

Funny Story 1:
Hire an expensive integration developer, but only give him a machine with 1 GB of memory and a weak CPU. So his machine crawls during debugging code in WebSphere Integration Developer.

Funny Story 2:
Create a small database for almost every project which ends up having many of them after a few years. Then spend millions of dollars if not more, often unsuccessfully to integrate these scattered and unruly databases when business needs to have data from all of them.

Tuesday, July 6, 2010

Application Level Software vs. Enterprise Level Software

While the left side should be valued; the right side should
be added to reach to higher level of maturity and realize the
efficiency, effectiveness, predictability and consistency of every project.

Application Level SoftwareEnterprise Level Software
Business rules are being internalized and imbed in the codeBusiness rules are
externalized and can be
deployed to and shared by
multiple application building
blocks
Emphasize implementabilityEmphasize extensibility
and reusability
Solve the problems at hands within a projectSolve the problems at hands
within the context of enterprise
Often modulize code at function,class, and component levels Modulize code to reach to
service and building
blocks levels
Tend to not to respect the boundariesFollow the service and
building blocks boundaries
Only the project related domainas it domain backgroundThe entire business segment as
its domain background
Focus on code syntax optimizationFocus on service/component
boundary setting
Pieces on hands are the big pictureEmphasize how smaller pieces
fit into the big picture
Often treat every project as its ownTreat every project as
an integration project
Loosely following industry
standards such as LDAP forsecurity repository
Empasize using industry
standards
The barriers among transactional, operational, integrational,analytical, and batch modules are highThe barriers among transactional, operational,
integrational, analytical,
and batch modules are broken
Often use the project name as boundary setter,
for example, com.companyname.projectname
Use business architecture blocks
as the boundary setter,
for example,
com.companyname.
businesssegmentname.
businessrule
Skillset tend to be genericThe right mixture of specialists
and generalists at building
blocks level
Often take a project viewTake portfolio view
Often dive into nitty-gritty line of code optimizationEmphasize the code
organization
Starting from project specific requirementStarting from
business architecture
The lines among business rules, business processes, business events, business data, business contents, business intelligence and etc. are blurredThe lines among those are
intentionally defined and well
integrated using controlled ways
On time delivery, under budget and work as being intended with less bugs for that project are main successful indicatorsScalable, extensible and
evolvable with ease and
costing less are added