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.

	Agreeable	Capable/Marketable	Knowledgeable
1	Y	Y	Y
2	Y	Y	N
3	Y	N	N
4	N	N	N
5	N	Y	Y
6	N	N	Y
7	Y	N	Y
8	N	Y	N

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.

From Business Building Blocks to Software Building Blocks

Business Building Blocks	Software Building Blocks
Business Vocabulary	Business Vocabulary Management and Repository
Business Data	Metadata, DBMS, MDM, Data Quality, Data Integration
Business Domain	Domain Driven, Domain-specific Industry Standards (ACORD, IAA, REA, IFX, etc.)
Business Information	Business Intelligence and Reporting
Business Content	Content Management, File Management
Business Rule	Business Rule Management
Business Process	Business Process Management, Business Activity Monitoring
Business Event	Business Event Management, Complex Event Processing
Business Service	SOA
Business Experience	User Experience, Unified User Communication Channels
Business Security	Identity 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.

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

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.

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.

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 Software	Enterprise Level Software
Business rules are being internalized and imbed in the code	Business rules are externalized and can be deployed to and shared by multiple application building blocks
Emphasize implementability	Emphasize extensibility and reusability
Solve the problems at hands within a project	Solve 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 boundaries	Follow the service and building blocks boundaries
Only the project related domainas it domain background	The entire business segment as its domain background
Focus on code syntax optimization	Focus on service/component boundary setting
Pieces on hands are the big picture	Emphasize how smaller pieces fit into the big picture
Often treat every project as its own	Treat 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 high	The 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 generic	The right mixture of specialists and generalists at building blocks level
Often take a project view	Take portfolio view
Often dive into nitty-gritty line of code optimization	Emphasize the code organization
Starting from project specific requirement	Starting from business architecture
The lines among business rules, business processes, business events, business data, business contents, business intelligence and etc. are blurred	The 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 indicators	Scalable, extensible and evolvable with ease and costing less are added

Enterprise Social Software as an IT Project Platform

There is no doubt that enterprise custom application software is a type of social activities: people with different skills, experiences, work habits, even personalities work together to deliver something that can add values to business stakeholders.

The collaborative nature of IT project is more paramount when team members come from different locations (inshore and offshore), systems, and departments.

What the enterprise social software has tried to solve is exactly that: collaboration, although in a much broader sense. Here is the definition, enterprise social software is, “a system of web-based technologies that provide rapid and agile collaboration, information sharing, emergence and integration capabilities in the extended enterprise.” (http://www.aiim.org/What-is-Web-2.0.aspx).

Andrew McAfee listed 6 functionalities of enterprise social software (http://sloanreview.mit.edu/the-magazine/articles/2006/spring/47306/enterprise-the-dawn-of-emergent-collaboration/):

• Search: allowing users to search for other users or content
• Links: grouping similar users or content together
• Authoring: including blogs and wikis
• Tags: allowing users to tag content
• Extensions: recommendations of users; or content based on profile
• Signals: allowing people to subscribe to users or content with RSS feeds

Dion Hinchcliffe added 4 more:

• Freeform function: no barriers to authorship (meaning free from a learning curve or from restrictions)
• Network-oriented function, requiring web-addressable content in all cases
• Social function: stressing transparency (to access), diversity (in content and community members) and openness (to structure)
• Emergence function: requiring the provision of approaches that detect and leverage the collective wisdom of the community

All of these 10 are completely relevant to the entire enterprise software life cycle. I especially value the “no barriers to authorship” feature because it can greatly expedite the knowledge accumulation and sharing. I have always advocated the work stream that is independent of project stream to prepare for things needed for projects. For instance, it will be almost infeasible for business to sponsor a project called Business Vocabulary project. There are no direct benefits seen from their angles. However, Business Vocabulary is a key foundation for any projects. We often find out that all kinds of business vocabularies being embed at the end of long requirement document repeatedly and inconsistently. With the enterprise social software, we can encourage everybody, I mean everybody, especially business people to put their understanding on a definition of a piece of vocabulary there for others to criticize and give feedbacks. In a few years, there will be complete and accurate business vocabulary repository. People who ever contribute to it will see the benefits and take pride of it: team work, right?

Many of software tools must incorporate features of enterprise social software right now or in the near future. Otherwise, they will become irrelevant. For instance, IBM Rational RequisitePro 7.0 enables “anyone with Web access, independent of his or her platform, can view, author and manage requirements quickly and efficiently without having Rational RequisitePro loaded on their machine. Project administration can be done via the web too.”

The desirable scenario is to conduct software project from project management, requirement, architecture, design, code publishing, and quality control entirely on the web using enterprise social software as the platform. The RIA (Rich Internet Application) technologies such as AJAX, Flash and JavaFX will speed it up for sure.

Since everybody can see how Google Docs works, I will use it as an simple example. The word description, UML diagram and tables flow and mesh up naturally in Google docs although primitively, although the diagram drawing part must be enhanced significantly to draw all types of UML diagram. It should also include diagram organizations that only include folders holding diagrams. Nevertheless, it represents the right direction for utilizing enterprise social software. A business analyst can write requirement using word features and draw UML diagrams. He can then publish his document on the web. All stakeholders can see it immediately and more importantly provide feedbacks which can be appended to the document. Or they can modify the document directly. The document comparison feature will allow interested parties to trace the changes people have made all along. The involved parties can also tag the document, which enables more efficient searches.

Enterprise social software is a key enabler of IT project. Let’s use it to unleash the power of the true collaboration.

The Power of Zachman Framework

More often than not, I like things that are natural and simple. The beauty of Zackman Framework is just that: natural and simple. In these years as an architect, I have referred back to it many many times, especially during early years. Now it has kind of printed into my brain with the vivid picture and molded my thinking processes when conducting architecture and design.

Zackman Framework has two dimensions out of box. The horizontal dimension uses the 5W+H (What, Where, When, Why, Who and How). I still remember at the first composition class in primary school, the teacher told us how to use 5W+H to tell a complete story. It helped. It is surprising that this rudimentary stuff can apply to the IT architecture and can do it so well.

The vertical dimension is harder to understand than horizontal one because it involves the level of details and changes of perspectives from top to bottom. I have seen the struggles even among experienced IT professionals to be able to peel the different layers of details either from inside-out or from outside-in. And yet this is one of the most essential skills especially for IT architects. The vertical dimension is top-down in nature, which means when it flows from Contextual, Conceptual, Logical, to the Functioning Enterprise, the pictures get narrowed and more details revealed. One of most striking powers of this layering is that how clearly and naturally it switches from the business concerns/perspectives to IT perspectives. People like to talk about business and IT alignments, often end up paying lip services due to the lack of grasping how the information/knowledge flows from business to IT. This vertical dimension can definitely help.

The intersections of the rows from horizontal dimensions and columns from vertical dimension form 36 cells, which cover the most complete and inclusive concerns among all the popular enterprise architecture frameworks. People can easily find homes for the concerns from other frameworks.

For instance, for the famous 4+1 View framework, its Logical view can be related to the third row – System Model; and yet the later is richer because it goes further as to 5W+H. Its Process View can be related mainly second and third cells of “How” vertical dimension. Its Physical View can be related to the first three cells of Technology Model. Its Development View can be related to row Detail Representations. Its Use Case/Scenarios View can be related to middle cells of Business Model row. The more powers go to the fact that the neighbor cells of each cell serve as its context, so people will never lose sight of where they are when addressing the specific concerns.

Another well-known framework, The Open Group Architecture Framework (TOGAF), its four architecture categories can also easily be mapped to the Zackman Framework: the Business Architecture can be mapped to the first two rows of Zachman; the Data Architecture can be mapped to cells in the row “What”; the Application Architecture can be mapped to the row of System Model; the Technology Architecture can be mapped to the row of Technology Model.

One of main complaints from IT practitioners is that the Zackman Framework tends to be documentation heavy: it sounds scary that 36 cells will correspond to 36 documents if each cell just generates one document. Making 36 documents consistent and cohesive across time span will be extremely costly in larger enterprise, not even mentioning to absorb them by team members. I have found this complaint almost groundless. First, due to its top-down layering nature, there will be much less documents in first two rows. The content of these documents will get enriched when moving down these rows. Secondly, I have proposed so called “two work streams” approach (will talk more in different blog entry): project stream and support stream. The support stream will largely handle the document repository for many cells. Enterprise social software (aka Enterprise 2.0) can be used to expedite the creations and consumptions of these documents.

The Zackman Framework is more of taxonomy of enterprise IT than of a methodology, which means it does not address how people will arrive at the artifacts that these 36 cells will need to produce.

I have long promoted the so called “big picture guided” software development to supplement and remedy the weakness of Agile methodology (will talk more in different blog entry). Regardless to their roles and positions in IT, every team members should have certain levels of understanding about the big picture. Their angles and depth of this knowledge might vary depending on their interests. This belief is largely motivated by the Zackman Framework. Its first two rows (Contextual and Conceptual) will form the solid big picture for any IT practitioners. My Layered Painting SDLC is a great match to implement the Zachman Framework.

I strongly believe that every IT practitioner should know the Zachman Framework. Each profession has its own way of thinking and behaviors, which is molded by training and long time practices. The Zachman Framework is a very powerful mean to mold an IT practitioner into a true professional.

Business Architecture – a Further Explanation

At the business segment/unit level, more than anything else, these three technical areas are at the core of any IT shops if they want to conduct IT projects consistently, predictably, effectively and efficiently (every word counts here). They are: business architecture, data architecture, and solution architecture. The rest is supplemental. Without knowing what they are and how to utilize their power and potentials, an IT shop will not be successful, period, end of the story, “Yes, Sir”. People may score now and then, but they will not always score.

Among these three, business architecture has caused most confusion and has been recognized the least. And yet, it is THE most critical one.

When you talk to business people about business architecture, especially those who are in charge of business strategy, they often stare at you and make you feel you are talking some nonsense, if not hurt their feelings. They might inform you that they ARE the business architects. How come there is different business architecture from IT side? You are stepping on my toes.

Some of IT folks may also feel the same way. If examining the texts about business architecture, we must admit that the confusion is almost a self-inflicted wound, because even some IT architecture experts are having troubles to explain the business architecture and the differences between business architecture on the business side and the business architecture on the IT side.

Here is one of the most concise and yet thorough definition about business architecture from The Object Management Group – Business Architecture Special Interest Group (BASIG), since it is not that long, I will paste here for the sake of completeness,

“

Business Architecture Overview

Business Architecture defines the structure of the enterprise in terms of its governance structure, business processes, and business information. In defining the structure of the enterprise, business architecture considers customers, finances, and the ever-changing market to align strategic goals and objectives with decisions regarding products and services; partners and suppliers; organization; capabilities; and key initiatives.

Business Architecture primarily focuses on the business motivations, business operations and business analysis frameworks and related networks that link these aspects of the enterprise together.

In order to develop an integrated view of an enterprise, many different views of an organization are typically developed. The key views of the enterprise within the business architecture are: 1) the Business Strategy view, 2) the Business Capabilities view, 3) the Business Process view, 4) the Business Knowledge view, and 5) the Organizational view.

The Business Strategy view captures the tactical and strategic goals that drive an organization forward. The goals are decomposed into various tactical approaches for achieving these goals and for providing traceability through the organization. These tactical and strategic goals are mapped to metrics that provide ongoing evaluation of how successfully the organization is achieving its goals.

The Business Capabilities view describes the primary business functions of an enterprise and the pieces of the organization that perform those functions. This view further distinguishes between customer-facing functions, supplier-related functions, business execution, and business management functions.

The Business Process view defines the set of strategic, core and support processes that transcend functional and organizational boundaries. It sets the context of the enterprise by identifying and describing external entities such as customers, suppliers, and external systems that interact with the business. The processes also describe which people, resources and controls are involved in the process. The lowest process level describes the manual and automated tasks that make up workflow.
The Business Knowledge view establishes the shared semantics (e.g., customer, order, and supplier) within an organization and relationships between those semantics (e.g., customer name, order date, supplier name). These semantics form the vocabulary that the organization relies upon to communicate and structure the understanding of the areas they operate within.

The Organizational view captures the relationships among roles, capabilities and business units, the decomposition of those business units into subunits, and the internal or external management of those units.

In addition to the above views of the enterprise, the relationships connecting the aforementioned views form the foundation of the business architecture. This foundation provides the framework that supports the achievement of key goals; planning and execution of various business scenarios; and delivery of bottom line business value.

”

I must say this is excellent stuff. What it tries to say is that business architecture takes holistic view on the enterprise as a whole and business segment as the part of the whole. Under it, there are five sub-views, which the business architecture will integrate them together. This definition addresses the first two rows of Zachman Framework: Contextual and Conceptual. To me, it still does not go far enough to differentiate business architecture on the business side and business architecture on the IT side. With this solid foundation, here is my further explanation:

1. Business architecture is the most critical bridge between business and IT. A business architect must not only have intimate knowledge and deep understanding about the business segment he is in like what the above describes, but also must understand how IT functions and how IT people such as other types architects think and behave. The business architect must be willing and feel comfortable to closely work with IT people. These are the first layer of divergence between business architecture on the business side and business architecture on the IT side: they have different key audiences.

2. The knowledge base and artifacts of business architecture must be easily consumable by IT people, which include but is not limited to: the structure of the content and the presentation style of the content. Therefore, it is absolutely essential for a business architect to have strong modeling (UML, BPMN) skills and story telling skills. The foundation of the knowledge base and artifacts is the business vocabulary repository, as the foundation of data architecture is metadata. The business vocabulary repository must be again independent of each on-gong project. A business architect should harvest the new vocabularies from each new project, at the same time feed and reuse the existing vocabularies to each new project, hence to form what I have called the circle of “Plant and Harvest”. This practice also applies to other three important repositories: business domain repository, business rule repository and business process repository. This is the second layer of divergence between business architecture on the business side and business architecture on the IT side: they produce and maintain different knowledge base and artifacts.

3. The business architecture will serve the IT projects from envision, solution, implementation, all the way through operation. So it deals with the entire SDLC process. Business architecture on the business side most likely will stop at the envision stage. This is the third layer of divergence between business architecture on the business side ad business architecture on the IT side: they engage in different stages of SDLC. So if we look at the Zackman Framework again, the business architecture is everywhere on the 36 cells.

I hope this short article can raise the awareness of the criticality of business architecture, and push the IT shops to formally setup the role of business architect and gradually utilize its powers. In large organizations, there might be two or more levels business architecture: enterprise level and business segment level. An enterprise level business architect without business segment level business architect will be easily getting shallowed because nobody has brain capacity to tackle so many areas of the business for a large enterprise. An enterprise level business architect should be more of harvester and synthesizer from divisional level business architect and a best practice promoter and governor.

Some pioneering originations have already put business architecture under the line of business and only dotted line to the IT, which is an excellent move. In the near future, more and more organizations will follow this course.

I will write more detailed stuff in the future around the topics of business architecture.

An Innovative Application Architecture

This diagram reflects the way I tend to design a typical multi-tier architecture for transactional and operational type of thin or rich client applications.

It takes some innovative approach to go a few steps beyond three tier architecture. A few popular design patterns are still being used here such as MVC, Service Façade, Domain Model, and DTO. However the differences will make this architecture much more flexible and modular by achieving higher degree of de-coupling.

I have always advocated that one of the most critical tasks for any architects in a project is to set the appropriate boundaries among the different software pieces. From vertical perspective, we can set boundaries from function, class, package, components, services, subsystems and etc. As the boundaries go wider, the higher circle will encapsulate the lower circles. From horizontal perspective, the most popular practice among IT shops is to set the boundaries using projects, which is what this architecture tries to address and avoid.

Here is what I like to point out further:

1. The diagram takes a holistic view to package code within a business segment (Life Insurance, for instance) in side a company, not each individual project view. So there are no project names in the packages.

2. The boundaries among the packages are set using four most critical packages: business domains, business rules, business processes and data services. This is an innovative way to achieve de-coupling and modularity.

3. The Service Façade package serves as the glue like a chassis to a car to tie everything else together. In the integration type of project, this will be different, which I will address later.

4. Further more, only the Service Façade package can access to the Data Service package, NOT any other packages. The data that Business Process and Business Rule packages need will be fed by Service Façade package. This is the cleanest solution to achieve the goal that Business Processes and Business Rules are self-contained, therefore, can be easily re-used, re-deployed, and extended – another innovation here.

5. Another unusual aspect of this architecture is that the Data Service package can call Business Rule package. One of the reasons is that sometimes Data Service needs business rules to form the WHERE clause of SQL statements.

6. The data that these packages needs will be carried by the Data Transfer Object (DTO design pattern), which in turn contains one or collections of Business Domain objects.

Layered Painting SDLC Methodology

This diagram summarizes my view on SDLC methodology, which gathers my experience and thoughts, and research during these years delivering one project after the other. It is powerful, flexible and effective.

I will explain it later.

Starting Small – One Little Example

It sounds anti-intuitive: the larger and more complex a project is, the smaller and simpler pieces I usually start to tackle the project after gaining an overall and high level landscape of the project.

For instance, when I face many dispersed data stores with all kinds of technologies and challenges such as data accessibility, data quality and data redundancy, and business demands a single view of their data (among other factors), I might tend to create a centralized ODS (Operational Data Store) using MDM architecture and techniques. This is a very daunting task actually, more than it looks like on the surface.

My starting point of this endeavor will be to just create a Person table with 4 attributes (First Name, Last Name, Birth Date, and SSN) to begin with. The goal is to put all the human beings from multiple systems into this one table. Sound too easy. As a matter of fact it is not. Actually, if we can accomplish this, we will test many situations down the road. Let me explain.

First of all, finding these human beings in these systems sometimes are is obvious. Some legacy systems store these 4 attributes in more than one table/file. First name and last name could be in one place and birth date in another place, and SSN yet another place. It takes a while to identify where they are.

Secondly, some legacy systems are not that accessible from outside world. Yes, you could spend some money to put technologies such as adapters into the systems. One of the problems is that these adapters for some systems are very expensive and might not perform well for large amount of data retrieval. So we need to settle the data accessibility issues.

Thirdly, we need to figure out the data refresh frequency of the data movement. For many reasons, the real time is not feasible. Batch job is mostly used in the situation. Then we need to deal with the permutations of things like how about the job fails.

Fourthly, we need to settle the data transportation: protocol, security and etc.

Fifthly, now the data is ready to be put into the Person table. But wait a minute. These data may not be consistent. For example, for the same person, one system may use his first name as Mike, one system may use Michael. Which one will be the winner? We can say whichever the last one in is the winner. Then if the person uses our system, one time he sees his first name as Mike, the other time is Michael. Will he like it? Or we can have little rules to guard this. Or we can use business users to mandatorily pick one. The same applies to the other three. For instance, how does the system know which SSN is the right one when one person has more than one SSNs? It is more complex than the first name situation.

Sixthly, OK, after all the 5 chaos, we finally have a Person table that store clean, complete and accurate data about these 4 attribute. We know the truth of each human being. We also know at this moment that some of the systems don’s store the truth. What should we do with these systems? The natural answer to some IT folks is, well, let’s write a module to reach to these systems and automatically fix the wrong data about these 4 attribute. Sometimes the business people accept and appreciate your help; sometimes they don’t. They know there are un-intended consequences if you change the data without them to examine it. I have had this resistance more than once.

Seventhly, who will own this pretty Person table and its data? Since there are already teams that own their own systems, this Person table is new and does not belong to and originate from any single systems, it could easily become an orphan. Along the same line, who will govern the table, for one thing, to make sure it will always store the clean, complete and accurate data in the future? Some politics even could involve here.

In summary, by just tackling one table with 4 attributes, we can gain and know a lot. For instance, can we deal with all the 7 situations? If not, people will wonder that if we are not capable of even one rudimentary table with 4 attributes, are we capable of handling much more complex tables, their relationships and attributes with larger volumes? So it tests us, which is very important because IT people often feel stronger than what we actually can do. It is called “wise” when we know our true capabilities. And based on that, we can set the real expectations with our business partners, instead of disappointing them one after another, or digging around excuses, or worse, finger-pointing each other.

So starting small is not because we are timid; it is because there are many benefits by doing that. I only use one little example to illustrate how and why it is as such.

Business Architecture Repository

One of the most important deliveries of business architect is to build the following repository:

• Business Vocabulary Repository
• Business Domain Model Repository
• Business Rule Repository
• Business Process Repository
• Business Event Repository

These repositories should be independent of individual project repository. Business architect should take pieces of business rules, processes and etc. from each project to contribute to the related repository. Each project should in turn take reference from these repositories. This is another instance of the so called “Plan and Harvest” paradigm.

The repositories can be organized by each business segment, for instance, retirement solutions segment, life insurance segment, and group protection segment.

It significantly reduces the power of any documents if they are not readily and easily accessible by every team member, not easily searchable, and don’t allow comments and feedbacks. A very common practice in many IT shops is to write documents in word document and put them in shared drive. This practice has severe limitations.

I will propose to utilize so called Enterprise Social Software such as wiki (I will post another blog, “Enterprise Social Software as an IT Project Platform” soon) to facilitate the celebrative creation and consumption of these repositories.

The Fundamental Enterprise Reference Architecture Blueprint

This Enterprise Reference Architecture Blueprint is meat to break the barriers of and addresses the integration, transactional, operational, analytical, and batch applications in a cohesive manner within the same architecture space, which not many IT shops have ever done.

It is very easy to understand and has low learning curve.

It identifies the most critical and fundamental components and integrate them in clean and standard ways. And yet, it will facilitate the extensibility, which means other components can be plugged to the framework seamlessly.

This is a risky endeavor. It can be either overly simplified or overly complex. And yet, during these years in IT, one project after another in different industry and circumstances, I do find some overlapping architecture themes among them. Some fundamental and yet powerful practices that demand not huge learning curve but some disciplined habits and some training can make huge differences.

The distance between wasting a million or more and saving a million or more in relatively large IT projects is much shorter than most people could have realized, imagined or been willing to admit.

People, especially among non-technical people, like business stakeholders often wonder why IT is so expensive.

What most of projects and IT shops really need are not expensive and fancy software from famous vendors; instead, with some common sense and strong people, who have the right mixture of non-technical and technical skills and some proven practices and disciplines, they will be better than at least 80% of their competitors and yet spend less than at least 15% to even 30% money. These are not empty promises.

Open Source in the Cloud

Open source in the cloud represents future for enterprise computing. The combined power of open source and the cloud computing will serve at least 70% of use cases in the enterprise. The rest will be shared by big vendors like IBM, Oracle, SAP and Microsoft.

Knowledge Sharing and Accumulation

Knowledge sharing and accumulation are among the most important practices to knowledge workers, which IT professionals are part of them.

You often see IT teams stand still after several years: they do the things in the same ways; they have same work habits; they have same mindsets. One of reasons to what have happened is the lack of knowledge sharing and accumulations.

One of the most important tasks of IT leaders is to facilitate and encourage knowledge sharing and accumulation among team members.