Build, Buy or Reuse: Services

The one of the most flaunted benefit of SOA is reuse of services. But it is one of the least used aspects of SOA. But Why so?

In enterprises there is no framework exist which can evaluate a service/service requirement which help in reach a decision of Build, Buy or Reuse. To fill up this gap, I have developed a framework. This framework has three aspects:

1. Appraisal Structure
2. Evaluation Criteria
3. Influencers

Appraisal Structure

The Appraisal Structure offers a classification for the types of considerations within the context of the business. The considerations and decision to build, buy or reuse fall into the following categories:

a. Strategic
b. Tactical
c. Operational
d. Business
e. Technical

Strategic considerations deal with the long-term vision and direction of an enterprise. These include:

• Market Share and Differentiation
• Growth
• Strategic Change Management

Tactical considerations deal with the short-term decisions and direction of an enterprise. These include:

• Current Project Portfolio
• Cash flow considerations
• Time consumption considerations

Operational considerations deal with the operational aspects of a project or a portfolio of enterprise. These include:

• Governance
• Change Management
• Skills
• Support and Maintenance

The business considerations are the ones that support the short- to medium-term objectives of the business. These include:

• Contract Management
• Depreciating of Assets
• Internal or External Provision

Enterprise have a technical strategy—one that states what technologies can be used and for what purposes. Considerations in this category include:

• Technology Considerations
• Technology Choice
• Interoperability/Integration
• Repository of Assets

Evaluation Criteria

There are eight Evaluation criteria identified eight attributes that affect Build, Buy or Reuse decision of services.

• Delivery Time
• Complexity
• Investment
• Expense
• Maturity
• Requirements compromise/match
• Maintenance
• Support




Influencers

There are five influencers. Each influencer has attractive and repulsive force field. Which force field will be more effective depends upon particular scenario – internal and external environmental conditions.

• Investment: It has one of the strongest force field – attraction as well as repulsive. This influencer has numerous aspects such as remaining cost-neutral RoI, profitability, affordability, and finally the cost implications of not doing it.

• Expenses: This influencer affect any decision on continuous basis. Investment and expenses in combination cover financial aspect of Build, Buy or Reuse decision. Like Investment, Expense also has multiple views – Cash Flow, ToC, etc.

• Quality: In market one with right quality wins keeping other parameters constant. Therefore Quality of Service (QoS) plays major role while making Build, Buy or Reuse decision. This influencer is also multi facet. Most of the abilities or non functional requirements are covered under Quality head.

• Time: In fast changing environment time is very critical. Time to market is one of the important parameter which affects Build, Buy or Reuse decision.

• Sustainability: Due to fast pace of technological and business environment evolution, obsolesce of a particular service and effort needed to keep it updated drives Build, Buy or Reuse decision.

The framework is very general in nature. It must be tweaked to a particular enterprise business environment, vision, goal, objectives and tactical needs.

Reference: The Architectural Journal (Microsoft) 20

Top 16 lessons from Real world BPM Projects

DO

• Start with an low hanging fruits – easy to implement, least politicized
• Document the process in detail
• Establish a simple ROI metric for initiative that is meaning for business
• Do engineering not over engineering
• Insist on multiple iterations
• Use business process needs to compare offerings
• Hire help
• Plan for enterprise convergence
• Change is inevitable
• Work in cooperation with process improvement (Six Sigma, Reengineering, Lean etc) initiatives.


DON’T

• Revolution in process engineering
• Go overboard with process performance metrics
• Wait for complete consensus on the new process before getting something up and running
• Allow Scope creep
• Focus on technology instead of Business functionality of BPMS
• Try implement complex process in first go

Enterprise Process Assets

Enterprise Process Assets are artifacts which facilitate execution, maintenance, retirement and improvement of a process. Enterprise Process assets can be categories into:

· Processes and Procedures
· Corporate Knowledge Base

Processes and procedures are part of any Enterprise Assets because a process or procedure facilitates lifecycle of another process. For example retirement process manages retirement of a process.

Corporate Knowledge Base forms large chunk of Enterprise Process Assets. It get accumulated a various projects get executed. Few of the examples of Enterprise Process Assets which are of Corporate Knowledge Base are:

· Formal and informal plans
· Policies
· Lesson learned
· Risk data
· Historical information
· Earned Value data
· Process measurement data
· Project files from previous projects
· Issue and defect management data

Enterprise Process Assets management is of very important to manage processes and projects in efficient manner.

Template Based Design Technique - Part 2

Now here is a solution of the design problem I posted in Template Based Design Technique.




This diagram not only covers the flow explained in Template Based Design Technique but also CRUD operations on Resume and Resume Template. This solution assumes God’s list is not updatable via any user interface, you need developer to update God’s list.

Role Based Authentication & Authorization

Today’s most of the applications have role based authentication and authorization systems. On the surface it seems that it is very simple and straightforward but as we dive into details, various design challenges emerges.

In simplistic terms role based authentication and authorization can be depicted as



User 1 is assigned to Role 1
User 2 is assigned to Role 1, Role 2 and Role n
User 3 is not assigned to any Role
User p is not assigned to any Role

Role 1 has Permission 1 and Permission 2
Role 2 has Permission 2
Role 3 has no Permission
Role n has no Permission

Systems has Permission 1, 2, 3, …, m

As we go into details of Figure 1, one easily deduces that system can have orphan users, roles and permissions, which may not be feasible state for a system.

While designing a role based authentication and authorization architect and designers have numerous options and some of the options may be conflicting.

Option Type: Orphan status
Orphan Users -- Allowed/Not Allowed
Roles -- Allowed/Not Allowed
Orphan Permissions -- Allowed/Not Allowed

Option Type: Permission Type
Permission -- Only Positive/Only Negative/Both

Number of Roles to a User
One Role per User
Multiple Roles per User

Software Architecture

Software architecture is formulation of optimum interaction among components keeping current and foreseeable future requirements (functional and non functional) in view while ensuring that required compliance and required industry standards are followed.

Lucky 13

While doing my job as software architecture I follow certain rules. I call them as Lucky 13. I have borrowed these principles from different streams of knowledge. Few of them are just picks and few are modified to fit software architect’s job description.

1.Be Lazy: Do not reinvent wheel, also what ever I create, it should be reusable within time and resource constraints -- From Object Oriented Principles
2.6 Wives and 2 Husbands Principle: 6 Wives – What, When, Why, Who, Where and To Whom. 2 Husbands – How and How many/much -- From 6 Sigma and Lean
3.One plus One is Eleven: When two heads work together their synergetic output is more than arithmetic summation -- Extreme Programming
4.Democracy is good but Veto system is required: In case of dispute there must be a authority to take decision à Political Science
5.One is not enough: If there is only one way of achieving goal/target, more grey matter is required -- War Theory
6.Nothing is future proof: No one can predict future only guess. Today’s systems is tomorrow’s legacy -- Experience
7.Organization hierarchy governs visibility: As persons move in Organization/Project hierarchy has more visibility of overall picture -- Organizational Theory
8.Learn Daily: The day you do not learn some thing, deduct that that day from your experience in resume -- Experience
9.Business has Money and veto power: Architecture might be superb but if there is no money and business requirement then it is not a workable solution -- Experience
10.Process’ absence as well as presence has its own burden: No or little process invites chaos while excessive processes brings red tape -- Process and Control Theory
11.Time and will are pre-requisites: To active a target with given constrains Time and will power are pre-requisites apart from resources -- Time Management and Psychology
12.Perfection is an illusion: For worldly challenges good enough solutions are sufficient -- Philosophy
13.Be an architect not consultant: Consultant is like Seagull. He flies high, zero on some thing good, take that good thing, create some disturbance, leave shit behind and fly way -- Experience