Customer Relationship Management (CRM)
Data Farm Inc.ฎ

The Technical "Know-How"
Home Executive Summary Investors Trade Secret Compression Encryption Data Streaming Business Intelligence
Check List: Brainstorm - Selling Your Architect
The goals of an architect is to sell his architecture, brainstorm with the team, win over management and meet the client's expectations. Brainstorming brings more and better ideas plus make everyone on the team feels that he or she contributed in building the project. Doing a great job and working hard and getting management involved are key of wining over management. Clients are a tough sell and you need to qualify the clients, work with them, answers all their questions and address all their concerns.

My Divide and Conquer
In computer science, divide and conquer (D&C) is an important algorithm design paradigm based on multi-branched recursion. A divide and conquer algorithm works by recursively breaking down a problem into two or more sub-problems of the same (or related) type, until these become simple enough to be solved directly. The solutions to the sub-problems are then combined to give a solution to the original problem.

How do I implement Divide and Conquer?
For Divide and Conquer, the following are my tactics:

     • Algorithms
     • Data and Data Structure
     • Techniques and strategies
     • Nice to have and have to have
     • Common sense
     • Reusability
     • Architect Templates
     • Business Plan Templates
     • Do not reinvent the wheel
     • If it works do not fix it
     • What is the latest and the greatest
     • Ask the experts
     • Get help if help is needed
     • Consult your managers and clients
     • Work and brainstorm the architect with your team

We will cover some the tactics rather quickly:

     • Algorithms
     • Data and Data Structure
     • Short Architect Templates
     • Short business plan

Algorithm definition:
A step-by-step problem-solving procedure, especially an established, recursive computational procedure for solving a problem in a finite number of steps.

Data and Data Structure
A data structure is a particular way of storing and organizing data in a computer so that it can be used efficiently.
Different kinds of data structures are suited to different kinds of applications, and some are highly specialized to specific tasks. Data structures provide a means to manage large amounts of data efficiently, such as large databases and internet indexing services. Usually, efficient data structures are a key to designing efficient algorithms. Some formal design methods and programming languages emphasize data structures, rather than algorithms, as the key organizing factor in software design. Storing and retrieving can be carried out on data stored in both main memory and in secondary memory.

How do we think in term of Data and its Structure?
How you manage a river and its flashfloods?
We need to cover the following to do justice to Data and Data Structure.

     • Data era
     • The significant of data
     • Intelligence
     • Speed and limitation

     • Technologies
     • Forms of data
     • Digitizing data
     • Physical and logical
     • Conversions
     • Normalization and de-normalization

     • Input and Output
     • Target Audience
     • Producers-Consumers

     • Data Cleansing
     • Data Certification

     • Memory and Secondary storages
     • Transport of data
     • Types of storage

     • Gateways
     • Hosting
     • Encryption
     • Security

     • Language support - built-in data structure
     • Hardware support (data bus)

Short Architect Templates
System Architect:
A system architecture or systems architecture is the conceptual model that defines the structure, behavior, and more views of a system. An architecture description is a formal description and representation of a system, organized in a way that supports reasoning about the structures of the system,

A system architecture can comprise system components, the externally visible properties of those components, the relationships (e.g. the behavior) between them. It can provide a plan from which products can be procured, and systems developed, that will work together to implement the overall system.

Architect Lead:
The Architect is the technical lead who coordinates technical activities and artifacts throughout the project. He establishes the overall system architecture and interfaces, provides the use-case implementation, creates plans and guidelines and helps put together the development team.

System Architect Template:
System Architect is the overall system building blocks and interfaces. It represents the system tiers and data flow. It should present the following views:

     • Tiers
     • Deployment
     • Data Flow
     • Interfaces
     • Communication
     • Subsystems
     • Distributed Systems
     • User Interface (UI)
     • Shared libraries
     • Security
     • Performance
     • Testing
     • Assessment

The term Tier is synonymous with Layer. A system architect may have more that one tier, for example, an N-Tier architect consists for N number of layers or tiers. Each has a distinct function(s) in the architect. The following can be considered as an example of a tier:

     • Business-Model
     • User-View
     • Database
     • Controller-Servers
     • Web Services

This view is how system is distributed across servers, platforms or even technologies (Legacy systems, Java, Unix Box).

Data Flow:
It present how data is moved from one tier to another and if there is a need to data conversion and how it is handled.

The interfaces can come in different shapes and forms. For example, the following may be some of the system interfaces:

     • Browsers
     • Other Applications
     • Databases
     • Application Servers
     • Web (HTTP) Servers
     • LAN
     • Different Platforms
     • Different Technologies (Legacy systems, Java, JNDI, Unix Box)

Tiers, interfaces and objects and services may need to communicate and the architect has to address such communications. Communication may have different channels, protocols and forms. For example, the following are some of the communication types:

     • HTTP
     • FTP
     • IMAP
     • Sockets
     • XML
     • COBRA

A software system can be partitioned into a number of subsystems or units. Each subsystem can be development independently; it may require the development of a number of interfaces. Depending on the design and the partitioning of the system, this may be an advantageous and reduce time, effort and cost. The architect and system analyst may need to address partition question.

Distributed Systems:
Distributed systems provide sharing of resources and information over a computer network, remote sites and databases. Distributed system can open (Internet), closed (LAN) or some thing in between. Architecting such system may need to address the following:

     • Performance
     • Security
     • Errors
     • Scalability
     • Flexibility
     • Transparency (no control, no knowledge or ways test or how to resolve issues)

User Interface (UI):
UI is also known as View Tier. Such tier or an interface may run on LAN, browsers, PCs, or any where the users will be able to access the system. Architect may need to address UI and its accessibility.

Shared Libraries:
Shared Libraries can be addressed in the architect or design.

Security may be provided, by the system platforms, companies’ firewalls and security systems. The architect may have one or more tiers take on the system security responsibilities. Servlets, Database objects may perform some security tasks.

Identify the system bottlenecks and how are handled.

Testing is a crucial part of any system developments. The architect may need to address testing and it could be conducted on each of the system tiers, interfaces. He should flag if system testing may require special equipments. Risks and concerns should be also discussed.

Pros and Cons:
The architect should prepare a Pro and Con Sheet, where he would be playing the devil advocate.
The team members should be involved in the architect designs and give their feedback.

Assessment is the process of documenting, usually in measurable terms, knowledge, skills, attitudes and beliefs. Project assessment may include the following:

     • Project objectives have been met
     • Project artifacts have been completed
     • Project models and schedules have been updated.
     • Should the project move to the next phase


     • Do we have a clear proposed project?
     • Could we have a better project design?
     • What are project strengths and weaknesses?
     • What aspects of the project that might have been missed?
     • If we rewind the project tape (go back in time), what should we have done differently?
     • Return on the investment?

Objective and Subjective Assessment:

Objective assessment has a form of questioning which has a single correct answer. It is becoming more popular due to the increased use of online assessment and its questions are easy to answer. The questions would include true/false answers, multiple choice, multiple-response and matching questions.

Subjective assessment has a form of questioning which may have more than one correct answer or more than one way of expressing the correct answer. Its questions include extended-response questions and essays.

Short Business Plan
What is a Business Plan?
According to Wikipedia, the free encyclopedia:
“A business plan is a formal statement of a set of business goals, the reasons why they are believed attainable, and the plan for reaching those goals. It may also contain background information about the organization or team attempting to reach those goals.

The business goals may be defined for for-profit or for non-profit organization. For-profit business plans typically focus on financial goals, such as profit or creation of wealth. Non-profit and government agency business plans tend to focus on organizational mission which is the basis for their governmental status or their non-profit, tax-exempt status, respectively—although non-profits may also focus on optimizing revenue. In non-profit organizations, creative tensions may develop in the effort to balance mission with "margin" (or revenue). Business plans may also target changes in perception and branding by the customer, client, tax-payer, or larger community. A business plan having changes in perception and branding as its primary goals is called a marketing plan.

Marketing Plan:
A marketing plan is a written document that details the necessary actions to achieve one or more marketing objectives. It can be for a product or service, a brand, or a product line. Marketing plans cover between one and five years. A marketing plan may be part of an overall business plan. Solid marketing strategy is the foundation of a well-written marketing plan. While a marketing plan contains a list of actions, a marketing plan without a sound strategic foundation is of little use.”

Summary of Our Business:
We are presenting a Summary of our Business and Marketing Plans to help our supporters and investors perceive our project without overwhelming technical details that we have in our detailed Business and Marketing plans. Our Business and Marketing Plans will include the requirement, architect/design, budget, deliverables, management plans and milestones. We as a team believe that the business plan(s) should be the creation of our project on paper. This means that the project should be created on paper first, before the development of the project. Such creation will help eliminate errors, misunderstandings, bugs, overdesign, overlooked issues and items, and a number of business and architect-design-development issues. The creation may take more time and effort, but the overall saving of money, effort and time is well worth it.
The following are the topics in the summary of a Business Plan:

     • Introduction
     • Executive Summary
     • Proposed System
     • Technology Used
     • Business Description
     • Products/Services
     • Building a Running Model
     • System Components
     • Management Plan
     • Milestones
     • Competition
     • Risk Assessment
     • Business Position
     • Marketing Plan
     • Cost
     • Balance Sheet

Testing, Logger and Architect:
There is new title called Test Architect. The primary responsibility of a test architect is to provide technical leadership and strategic direction for their testing organization. Test architects focus on a diverse set of goals and perform a wide variety of tasks. Some spend time developing testing infrastructure, test authoring frameworks, or evaluating features in order to create complex tests. Some are in charge of a particular technology for their group. A test architect has in-depth knowledge of a variety of testing techniques and methodologies used. A test architect often provides technical assistance and/or advice to the test Manager.

What Software Testing?
Testing is the process of achieving error free system.
There should be a test plan, which includes unit test, stage development testing and system testing.
The design should include testing stages and plans. Testing teams and tools should be available.

System Performance and Bottlenecks:
To me architecting is a tool, God-given-talent, an art, an expression and a communication media. Knowledge, experience and an open mind to other views are key ingredients.

My analogy of an architect role is that of a Football Quarterback, who is the center of the entire offense. The Quarterback not only manages his team mates, but also has his eyes and ears on the opponent defense and their tactics. The Quarterback knows he cannot do the job alone and his success is tied to his team members' performance. Therefore, what would an architect would looking at when it comes to System Performance and Bottlenecks.
The following is project components and theirs Risks (high in red color) and Bottlenecks (underlined) associated with them:

Workers Artifacts - Data Resources Technologies and Approaches
     • Business-clients
     • Bstakeholders
     • Timeline
     • Change Control

     • Training
     • Marketing
     • Engagement

     • PM
     • Developers
     • Testers
     • QA
Task at Hand
     • Budget
     • Data (may not be available)

     • Documentation (Requirement, Analysis,...)
     • Standards
     • Development
     • Security
     • Risks

     • Testing

Project: artifacts
     • Scope - Size
     • Complexity - Deliverables
     • Expertise
     • Help
Software and Hardware
     • Tiers (MVC)
     • Frameworks
     • Components
     • Containers - Vendors
     • Servers - Browsers
     • Interfaces
     • Databases
     • Legacy System
     • Training
     • Java
     • Web
     • Mobile
     • Web Services
     • Rational Unified Process (RUP)
     • Agile - Scrum
     • Waterfall

     • Business Model
     • Data Models
     • Deign Model
     • Testing Model

Any of the items in the table can turn into a High Risk and or a Bottleneck. From the table we can see that the following can be both High Risks and also Bottlenecks:

     • Business-clients-stakeholders
     • Security
     • Interfaces
     • Legacy System

How to handle Risks and Bottlenecks?
Experience shows that most issues are kind of unique, but they do have a number of similarities.
The following is our guidelines of how to handle issues in general:

     • A good architect-design would eliminate most of the Risks and Bottlenecks.
     • Must identify the Risks and have both Risk analysis and handling
     • Must identify the Bottlenecks and the their cause.
     • The first answer is team work and brainstorm each issue with your team.
     • Work with your supervisors and the clients and keep them informed.
     • Look at previous experiences that are similar and how they were handled in the past.
     • Work the issue backward and try to find an answers - Critical Path approach.
     • Search the web for possible solution or an alternative.
     • Brainstorm Risk Acceptance, Risk Avoidance and Risk Transference.
     • Call friends and colleagues for help.

I try to view and envision any architect on the following levels:
Think like users and get in the mind of the users and how to make their experience a better one
The business goals and business processes
The interfaces between tiers and issues
Data and data flow:
Envision the data and its flow and transformation from end to end
How to keep thieves out and make it easier to clients
Bits and bytes:
This is hard to explain, I think of computer and data are nothing but zeros and ones.
Electronic signals:
The back and forth of the transformation of electric current to wireless signals or sounds.
I document everything I think off or do so I would not lose a thought and reuse my ideas and work.
"Organization half the work is done" I believe is supporting management for achieving goals. He who cannot be a good Follower cannot be a good Leader. A team is made up of leaders and followers, each takes a turn as the game progresses.
Been there and done that, so I try to help the team do a better job.
Been there and done that, so I try to help the team do a better job.
Been there and done that, so I try to help the team do a better job.
Bring my presentation to the audience level.

       Facebook Facebook Facebook Facebook Facebook
Thinking in
Data Access
Zeros & Ones
Plus Math
Data and
Check List Issues
Mobile-Browsers Standardization Templates Conversion Index Performance FAQ
Cloud Intelligent JSP Template Indexing DAO-XML Security Clients
Server Personal Multiple
Encryption Tracing & Transformation Errors & Logging Future
Security &
Business Intelligent
Shopping Cart
Compression Data Structures Scalability
Big Data
Business Transaction Ready to Use
  Internal &
Flexibility CRM
Data Refactoring Server Traffic   CLOB & BLOB Transparency End-to-End
Mapping & Farming       Encryption Availability Intelligence
Web Services       Compression Latency Marketing
New Technologies       Security Brainstorm (Team) Sales

About us Contact Site Map Support Privacy Terms All rights reserved