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.