Architecture
JSF is a Component based UI framework. It is industry endorsed framework governed by JCP
Provides cleaner separation of concerns; uses MVC architecture
Robust event handling architecture. Each JSF component hierarchy is associated with rich set of listeners
JSF has in-built plug-in architecture to support application scalability; any third libraries like Tomahawk (JSF enabled components) shall be easily integrated and extended.
Robust event handling mechanism
All UI components initiate OO web-application development. Thus JSF enabled web applications can leverage on rich-proven OO practices for rapid application development
Usability (Both Application end user and Application developer)
Increased user interface experience with rich client features like data grid, trees, dashboard features, auto-complete, auto-refresh etc
Increased application user productivity with the help of in-built features like asynchronous page rendering, automatic refresh of server data, reduced number of user clicks and auto page submissions
Multiple options to select JSF specification implementation frameworks like Sun RI, Apache My faces, JBoss Rich faces and Exadel’s facelets for application development
Comprehensive JSF tool support from leading industry vendors; such tools includes Eclipse, JDeveloper, IBM RAD, Sun Studio and JBoss Studio
Provides in-built validation framework to validate UI inputs. Significant reduction in development time; moreover validation framework uses latest JSTL enabled expression language
All JSF custom tags are JSTL/EL aware
Scalability
JSF rendering kit provides different rendering techniques to handle requests like WML, XML etc. In other words; it is not limited to HTML only. So JSF enabled application are scalable in nature to address different clients with out changing underlying business/data architecture
Provides seamless integration with Ajax technology. All JSF component tree model are Ajax aware; so any non-Ajax application can leverage on this excellent scalable feature. Again application developer has good support from open source frameworks like Ajax4JSF
Provides pluggable life cycle phase listeners. So JSF based application can be scalable to add in-built listeners against application’s future requirements
JSF is based on standard converters. Custom converters can be easily developed or extended for ever changing requirements
Maintainability
JSF based applications shall be maintained with ease; provides good separation from configuration files, backing beans, form beans etc. Backing beans shall be developed using POJO centric development model. If application leverage on ORM solution like Hibernate; then significant reduction in code; thus better management of the application
Clean separation of roles; Thus better managed application source repository both development and maintenance phase
Custom JSF components like progress bar, drag n drop, file movement etc shall be reused across the application. So there is no redundancy in source code.
30 May, 2008
28 May, 2008
27 May, 2008
Factors to be considered for productvity measurement of agile practices
Abstract
The Agile methodology really lacks its ability to collect the productivity metrics. Agile gives utmost priority to satisfy the customer with the help of frequent deliveries of working software. However there are several factors do exist to capture agile metrics. Following article discusses some of those.
Factors to be considered for productivity measurement
Following section list downs the different factors to be considered to measure the productivity of agile practices, viz., SCRUM, Continuous Integration, Workshops and Dual Monitors. Each factor might applicable to one or more agile practices.
1) Customer satisfaction
It is one of the better ways to measure the productivity of the agile processes or related practices. Each iteration/sprint will end-up with tangible output which is going to perceived or evaluated by the client according to his/her business requirements. So in this process no of customer feedbacks (good as well as not so good), his active participation frequency and delivery satisfaction rate (on the scale of 1-5) etc shall be measured.
Applicability: SCRUM, Continuous integration, Workshops
2) Reduced/Manageable risk
The number of risks envisaged and able to mitigate the risks with successful counter measurements per iteration. Also how team as a whole successfully managed the risk with in iteration with out affecting the delivery. It requires disciplined way to capture such instances during iteration. Best candidate would be Scrum Master.
Applicability: SCRUM
3) Improved quality
Quality differs from context to context. From the SCRUM aspect, it is reduced code review defects, increased design/architectural specific brain storming sessions, reduced build rejections from internal QC/ or client, Increased junior team member participants in design workshops, increase in review efficiency, reduce in number of failed attendees for SCRUM stand-up meeting, etc…
Applicability: SCRUM, Workshops, Continuous Integration
4) On time delivery
On time delivery of working software (with duly tested!) of all story points identified for the iteration. If any delay in delivery; then associated delay can be measured in number of person days / or IEH
Applicability: SCRUM
5) Innovation
The number of innovative ideas/best practices adopted to deliver out of box solution with in iteration. It might be good design strategy, improved code quality, increased automation by using good tools under all stages of SDLC cycle etc. Again it is in process matrix collection mechanism, Scrum Master is the best person to judge such initiatives.
Applicability: SCRUM, Workshops, Continuous Integration
6) No of Reusable components to the organization
How many reusable components are contributed to the organization from the project? Here code is fully tested and moved to client’s production environment. Any such code which does not have any customer obligations shall be moved organization’s reusable component repository. It can be measured across the projects over the period of time. This measurement shall be conducted against iteration or specific period of time.
Applicability: SCRUM, Agile process as a whole
7) Increased knowledge sharing activities
How many times from specific SCRUM team member shared his technical competency with others in the form of presentations, trainings, articles etc. Any such instances shall be captured.
Applicability: SCRUM
8) Team engagement
Team engagement during sprint, shall be calculated in the form of Ideal Engineering Hours (IEH). Also overall team engagement in the form of understanding requirement, design, code, review, testing, training, research etc shall be classified.
Applicability: SCRUM (Backlogs)
9) Burn down charts
Burn down chart is early warning system, which gives product owner how the team is performing to achieve user story points for current iteration. At high level; number of high level warnings occurred during sprint / or across the sprint(s) shall be measured.
Applicability: SCRUM
10) Personal Excellence
Capture information such as how many people with in SCRUM team are being certified for various technological tools/frameworks? How many people participated seminars, training programs? How many team members contributed to open source projects or initiatives? Thus increase in company branding etc...
Applicability: SCRUM
11) Agile maturity
Judge the team maturity with help of schedule over run, effort over run (directly related to matured way of conducting task estimation), what kind of task selection from team member during iteration planning, active participation instances in various workshops, retrospective meetings, stick on to realization of sprint goals, adherence to multiple project checklists etc. Any violations or innovative ideas should be captured as part of sprint.
Applicability: SCRUM
12) Compliance with respect agile principles/or number of tailor made approaches which violates agile principle
Capture any agile principle violations in the form of tailor made requirements; might be influenced by external stakeholder. Also identify number of agile principles being practiced on iteration basis. Derive such matrix at the end of each iteration. In my opinion it is the most important activity shall be considered with high priority.
Applicability: SCRUM, Workshops, Continuous Integration
13) Obstacles cleared per iteration
Capture number of blockers removed per iteration.
Applicability: SCRUM
14) Number of De-scoped functions/tasks over into next iteration
All de-scoped story points of the current sprint
Applicability: SCRUM
15) Number of retrospectives per iteration
How often SCRUM teams adheres to “Inspect and Adapt” principle? Identify number of retrospectives being conducted with in sprint. Also capture what are the types of retrospective meetings are being practiced and related feedback from the team.
Applicability: SCRUM
16) Implementation status of retrospective action items
It is number of outstanding retrospective action items from previous sprints.
Applicability: SCRUM
17) Number of functional tests / iteration or user story
It is a process of capturing number of functional tests developed and applied against user story points per iteration.
Applicability: SCRUM, Continuous Integration
18) Unit tests / iteration
Capture number of unit test cases against code developed per sprint.
Applicability: SCRUM, Continuous Integration
19) Number of builds / iteration
Capture number of successful builds / or broken builds per sprint.
Applicability: SCRUM, Continuous Integration
20) Number of functional defects / iteration
It is number of functional defects found by both internal QC team and client.
Applicability: SCRUM, Continuous Integration
21) Lines of code
It is mainly concentrated on development team productivity on lines of code delivered for the specific period. For example; KLOC/Person day. But most of the agile practicing companies discourage this approach as 50 lines of code with just variable declarations can’t be more productive compare to just 20 lines of code which does important business functionality. In my opinion it is most crud way to measure productivity; shall be discarded.
Applicability: SCRUM, Continuous Integration
22) Function Point
It is originally intended to use for project estimation. It revolves under Input, Output (Report) and data. Again as explained with LOC; one can not depend on FP for measurement for the simple reason, a simple CRUD operation will carry more function point where in most complex business scenario which does not have any output will carry less FP. In my opinion each FP should have weightage and determination of weight-age will ask for definitive discussion.
Applicability: SCRUM
23) Velocity
Sustained development pace of the team is determined by Velocity mechanism. Here it depends on number of story points delivered per iteration. Most of the agile practitioners recommend this approach to determine overall team productivity. Here also some fundamental question arises like “if team of 3 delivers 40 story points where in another team of 10 delivers 50 story points, so which sprint team is more productive?”
Applicability: SCRUM
The Agile methodology really lacks its ability to collect the productivity metrics. Agile gives utmost priority to satisfy the customer with the help of frequent deliveries of working software. However there are several factors do exist to capture agile metrics. Following article discusses some of those.
Factors to be considered for productivity measurement
Following section list downs the different factors to be considered to measure the productivity of agile practices, viz., SCRUM, Continuous Integration, Workshops and Dual Monitors. Each factor might applicable to one or more agile practices.
1) Customer satisfaction
It is one of the better ways to measure the productivity of the agile processes or related practices. Each iteration/sprint will end-up with tangible output which is going to perceived or evaluated by the client according to his/her business requirements. So in this process no of customer feedbacks (good as well as not so good), his active participation frequency and delivery satisfaction rate (on the scale of 1-5) etc shall be measured.
Applicability: SCRUM, Continuous integration, Workshops
2) Reduced/Manageable risk
The number of risks envisaged and able to mitigate the risks with successful counter measurements per iteration. Also how team as a whole successfully managed the risk with in iteration with out affecting the delivery. It requires disciplined way to capture such instances during iteration. Best candidate would be Scrum Master.
Applicability: SCRUM
3) Improved quality
Quality differs from context to context. From the SCRUM aspect, it is reduced code review defects, increased design/architectural specific brain storming sessions, reduced build rejections from internal QC/ or client, Increased junior team member participants in design workshops, increase in review efficiency, reduce in number of failed attendees for SCRUM stand-up meeting, etc…
Applicability: SCRUM, Workshops, Continuous Integration
4) On time delivery
On time delivery of working software (with duly tested!) of all story points identified for the iteration. If any delay in delivery; then associated delay can be measured in number of person days / or IEH
Applicability: SCRUM
5) Innovation
The number of innovative ideas/best practices adopted to deliver out of box solution with in iteration. It might be good design strategy, improved code quality, increased automation by using good tools under all stages of SDLC cycle etc. Again it is in process matrix collection mechanism, Scrum Master is the best person to judge such initiatives.
Applicability: SCRUM, Workshops, Continuous Integration
6) No of Reusable components to the organization
How many reusable components are contributed to the organization from the project? Here code is fully tested and moved to client’s production environment. Any such code which does not have any customer obligations shall be moved organization’s reusable component repository. It can be measured across the projects over the period of time. This measurement shall be conducted against iteration or specific period of time.
Applicability: SCRUM, Agile process as a whole
7) Increased knowledge sharing activities
How many times from specific SCRUM team member shared his technical competency with others in the form of presentations, trainings, articles etc. Any such instances shall be captured.
Applicability: SCRUM
8) Team engagement
Team engagement during sprint, shall be calculated in the form of Ideal Engineering Hours (IEH). Also overall team engagement in the form of understanding requirement, design, code, review, testing, training, research etc shall be classified.
Applicability: SCRUM (Backlogs)
9) Burn down charts
Burn down chart is early warning system, which gives product owner how the team is performing to achieve user story points for current iteration. At high level; number of high level warnings occurred during sprint / or across the sprint(s) shall be measured.
Applicability: SCRUM
10) Personal Excellence
Capture information such as how many people with in SCRUM team are being certified for various technological tools/frameworks? How many people participated seminars, training programs? How many team members contributed to open source projects or initiatives? Thus increase in company branding etc...
Applicability: SCRUM
11) Agile maturity
Judge the team maturity with help of schedule over run, effort over run (directly related to matured way of conducting task estimation), what kind of task selection from team member during iteration planning, active participation instances in various workshops, retrospective meetings, stick on to realization of sprint goals, adherence to multiple project checklists etc. Any violations or innovative ideas should be captured as part of sprint.
Applicability: SCRUM
12) Compliance with respect agile principles/or number of tailor made approaches which violates agile principle
Capture any agile principle violations in the form of tailor made requirements; might be influenced by external stakeholder. Also identify number of agile principles being practiced on iteration basis. Derive such matrix at the end of each iteration. In my opinion it is the most important activity shall be considered with high priority.
Applicability: SCRUM, Workshops, Continuous Integration
13) Obstacles cleared per iteration
Capture number of blockers removed per iteration.
Applicability: SCRUM
14) Number of De-scoped functions/tasks over into next iteration
All de-scoped story points of the current sprint
Applicability: SCRUM
15) Number of retrospectives per iteration
How often SCRUM teams adheres to “Inspect and Adapt” principle? Identify number of retrospectives being conducted with in sprint. Also capture what are the types of retrospective meetings are being practiced and related feedback from the team.
Applicability: SCRUM
16) Implementation status of retrospective action items
It is number of outstanding retrospective action items from previous sprints.
Applicability: SCRUM
17) Number of functional tests / iteration or user story
It is a process of capturing number of functional tests developed and applied against user story points per iteration.
Applicability: SCRUM, Continuous Integration
18) Unit tests / iteration
Capture number of unit test cases against code developed per sprint.
Applicability: SCRUM, Continuous Integration
19) Number of builds / iteration
Capture number of successful builds / or broken builds per sprint.
Applicability: SCRUM, Continuous Integration
20) Number of functional defects / iteration
It is number of functional defects found by both internal QC team and client.
Applicability: SCRUM, Continuous Integration
21) Lines of code
It is mainly concentrated on development team productivity on lines of code delivered for the specific period. For example; KLOC/Person day. But most of the agile practicing companies discourage this approach as 50 lines of code with just variable declarations can’t be more productive compare to just 20 lines of code which does important business functionality. In my opinion it is most crud way to measure productivity; shall be discarded.
Applicability: SCRUM, Continuous Integration
22) Function Point
It is originally intended to use for project estimation. It revolves under Input, Output (Report) and data. Again as explained with LOC; one can not depend on FP for measurement for the simple reason, a simple CRUD operation will carry more function point where in most complex business scenario which does not have any output will carry less FP. In my opinion each FP should have weightage and determination of weight-age will ask for definitive discussion.
Applicability: SCRUM
23) Velocity
Sustained development pace of the team is determined by Velocity mechanism. Here it depends on number of story points delivered per iteration. Most of the agile practitioners recommend this approach to determine overall team productivity. Here also some fundamental question arises like “if team of 3 delivers 40 story points where in another team of 10 delivers 50 story points, so which sprint team is more productive?”
Applicability: SCRUM
Linked-In QA
Stakeholder Interest
http://www.linkedin.com/answers/technology/software-development/TCH_SFT/234124-14255949
EA best practices to Individual Projects
http://www.linkedin.com/answers/technology/enterprise-software/TCH_ENT/234126-14255949
http://www.linkedin.com/answers/technology/software-development/TCH_SFT/234124-14255949
EA best practices to Individual Projects
http://www.linkedin.com/answers/technology/enterprise-software/TCH_ENT/234126-14255949
22 May, 2008
Dont justify agile based on productivity
It is often found that, many people adopt agile development process for quicker delivery. But it is thorough bad idea, with out understanding agile goals and true engineering practices. Productivity of an s/w person cant be measured in the form of lines of code, how many function point is delievered etc. Rather it will be more meaningful if it is associated like
Increased customer satisfaction (may conduct ratings)
Increase in the quality of delivery like no architectural issues under design phase, no design mistakes during production run, better quality code in context to better API usages, easier maintenance etc
Increased personal excellance in the form of better problem solving skills; communication with co-team members, external people
Contribution to online community, information sharing with in organization or outside organization
etc..etc..etc...many more
-
Increased customer satisfaction (may conduct ratings)
Increase in the quality of delivery like no architectural issues under design phase, no design mistakes during production run, better quality code in context to better API usages, easier maintenance etc
Increased personal excellance in the form of better problem solving skills; communication with co-team members, external people
Contribution to online community, information sharing with in organization or outside organization
etc..etc..etc...many more
-
06 March, 2008
Open group confrence proceedings - Bangalore, INDIA
Why Enterprise Architecture?
Following are the few reasons to start with:
Silo-ed applications
Inconsistent and Islands of data
Rigid technical infrastructure which are very hard to change
Change in business strategy to have competitive advantage
“Enterprise architecture should provide support to the business by providing the fundamental technology and process structure with the help of IT strategy”
Here IT is a responsive asset for modern business strategy.
Highlights of the conference proceedings
SONA as Networking Platform
In a keynote address, CISCO executive expressed his thoughts on today’s IT challenges in following areas:
Empowered Users
Real time information
Borderless Enterprise
Now a days business user’s are exposed to innovative user interfaces (like innovations from Google); and no means IT service company will escape by providing at par solutions which adheres to current user expectations
SONA (Service Oriented Networking Architecture) is open standard, which nicely fits in between Business Architecture and Technology architecture. It provides in built networking services like faster IP routing, data cache, security etc. With the help of SONA enabled applications; with in CISCO, enterprise applications response through-put increased to ~ 40%.
It also observed that, any strategy should be on business centric rather than people or technology centric; to stay competitive in modern business environment.
CISCO adopted TOGAF – ADM as architectural framework while developing SONA.
Managing Change in EA Program
Mr.Ron Baillie of Cathay Pacific shared his practical experience when introducing the Enterprise architecture program with in IT team. Initially there was lots of resistance from internal IT team to understand and adapt new enterprise concepts. Mr.Ron introduced several EA program innovative concepts like;
Having all EA principle (there were 06 principle’s to start with) in a cube.
Arranged many programs to understand such concepts; including his CIO
He highlighted few observations which are come out during EA program execution;
Motivate the people respect to the context (like cost= total no of First class empty seats…)
There must be Centralized architectural artifacts
Identify the key principles in EA program
Create an ownership for each principle
Roadmaps should be created for each EA components
Associate business matter experts for each roadmap
Also he highlighted EA is a journey; not an end point. Following are few principle’s he adopted in Cathay Pacific:
Simplicity
Modularity
Standardization
Measurement
Life Cycle
Etc…
Finally there is very interesting presentation slide; which shows picture were all fishermen rowing the boat in one direction. In an analogy he stated; it is very important in EA program whether all stakeholders are rowing same direction or not.
Introduction to TOGAF
Mr.Vishwanthan of C&CC solutions; Australia (TOGAF certified) gave a nice presentation on TOGAF 8.1. Few things about TOGAF;
1. TOGAF is a framework; not a architecture
2. TOGAF certification is all about checking one’s knowledge about TOGAF; not a check on skills or related implementation. Holds very good acceptance from enterprise architect’s community
3. It’s customer initiative; not from Open group
4. It is defacto industry accepted architectural framework. It can be used in conjunction with many architectural frameworks like Zachman, DoDAF, MDA, FEAF etc
5. Zachman and TOGAF compliment each other. TOGAF shall be used as implementation framework for Zachman.
6. Already there are several mappings exists respect to TOGAF; mainly
a. Zachman
b. MDA
c. DoDAF
d. COBIT
e. ITIL
f. FEAP
TOGAF shall be certified in two ways;
§ Directly taking the exam from Prometric center
§ Or attending the training from Open group authorized training institution.
One can build a business case for TOGAF as EA; providing sufficient strengths like
Ability to chunk-up the whole enterprise architectural program into different ADM phases. Here each ADM phase may run into several iterations; depending on the organization’s business complexity.
Avoid the redundancy in process to building new project
Avoid the silo-ed approach.
TOGAF 8.1 divided into three parts;
ADM (Core implementation phases)
Enterprise Continuum (TRMs, Federated EA’s etc…)
Resource base (Case studies, Glossaries, Templates, Evaluations etc…)
Also he emphasized on ADM and its relative importance in overall EA implementation program.
ADM is an iterative method; consists of totally 8+1 phases. Also there is preliminary phase to start with
Each iteration; there will be new decisions. So each decision should have adequate information on
Overall enterprise coverage
Level of detail to understand the decision
Time horizon to implement the decision etc…
Every phase is validated against the business requirements
Any decision will be based on Competence (business) and resource availability
Jason Uppal from QuickResponse, Canada; gave excellent insight towards TOGAF 8.1 by going through ADM phases. Below are few thoughts:
Business Requirements
These are also called as “Architectural Requirements” are nothing but set of wish lists which enterprise have, but preventing for implementation. So these are actual architectural requirements. It might include wicked problems as well. Wicked problems are one which is very hard to frame.
Architecture Vision
In this phase, EA should attack the wicked problems, apply the SMART objectives and also come up the statement of architectural work. If Architecture vision is set right; then rest of phases more likely to succeed. It is very important that EA must gain confidence from all stake holders.
Business Architecture
While developing business architecture, following are few areas should be considered for effective impact on overall EA program:
Effective business process
Impact of change on people
Implementable business process (think “Realistic” principle of SMART!)
Data architecture
What information is required to make an effective business process?
Application architecture
Cost effective way to deliver information system to make business process efficient
Infrastructure
Hardware, Software, People are required to deliver services to meet required SLA
Opportunities and Solutions
Ideal set of objectives/Initiatives (Technology is limiting factor; people & process change etc are key challenges!)
Migration Planning
Set of initiatives required to deliver architectural vision.
Define Value
Organization learning towards expected benefits from EA program. Also value of exploring current enterprise capabilities
KPI Governance
Define, Measure and Report architectural changes. Also study the corrective action and impact analysis on already defined phases of ADM due to change.
Brief on SMART objectives
All businesses need to set objectives for themselves or for the products or services they are launching. What does your company, product or service hope to achieve? Setting objectives are important. It focuses the company on specific aims over a period of time and can motivate staff to meet the objectives set.
A simple acronym to set the objectives is called SMART objectives.
Specific – Objectives should specify what they want to achieve.Measurable – You should be able to measure whether you are meeting the objectives or not.Achievable - Are the objectives you set, achievable and attainable?Realistic – Can you realistically achieve the objectives with the resources you have?Time – When do you want to achieve the set objectives?
Difference between Zachman and TOGAF
Following are few differences;
TOGAF tells step by step implementation of each step is dependent on other, where in Zachman framework does not have the dependency
Operations feature is not included in TOGAF, but Zachman got detailed information.
Proposed TOGAF 9 focuses on Governance, Portfolio management etc.
Enterprise conceptual model
Mr.Gundars Osvalds from BearingPoint, USA, gave short presentation on conceptual model in EA. Enterprise architecture conceptual model contains following sections; these conceptual model elements are interlinked and will drive each other.
Framework
Architecture
Life History
View
View Point
Abstractions
Framework concept
Select one or more framework (Federated architectural approach!) to arrive EA.
Zachman
TOGAF
Framework
DoDAF
FEAF
Enterprise Architects can be developed
In interesting presentation Jason Uppal from QuickResponse, ITAC level-2; opened up a nice discussion on how to develop an Enterprise architect. Here are few ideas:
Start working with some strategy in mind. Strategy should have direction (like Financial, Customer supplier, Organization objectives etc…)
Perform the litmus test using SMART objectives
Identify the current constraints (Area not to focus on)
Have a Guidelines (Area to focus on)
Develop a programmatic roadmap (Benefits, Costs, Risks, Why you???) for a business strategy. Provide expertise based on leadership to help and execute the roadmap
Study architectural views on People, Process and Technology for Business Architecture, Data Architecture, Application Architecture and Infrastructure Architecture
He advised audience to concentrate on “Wicked Problems” of business
More wicked problems, higher level of effort is needed to come up with realistic EA.
In spot light forum discussions, Mr. Allen Brown, CEO of Open group gave insight towards few standards like;
“Interoperable Enterprise” - Look for white paper from http://www.opengroup.org/cio/iop/index.htm
He also highlighted the current problems in enterprise; mainly Cross functional team culture, new business partners and stove-piped information.
He also stressed on having “Bounderyless Information flow” with in enterprise. Finally he concluded discussion by saying “Requirement defects are very expensive” and worldwide nearly 53% of defects are raised from business requirement.
Following are the few reasons to start with:
Silo-ed applications
Inconsistent and Islands of data
Rigid technical infrastructure which are very hard to change
Change in business strategy to have competitive advantage
“Enterprise architecture should provide support to the business by providing the fundamental technology and process structure with the help of IT strategy”
Here IT is a responsive asset for modern business strategy.
Highlights of the conference proceedings
SONA as Networking Platform
In a keynote address, CISCO executive expressed his thoughts on today’s IT challenges in following areas:
Empowered Users
Real time information
Borderless Enterprise
Now a days business user’s are exposed to innovative user interfaces (like innovations from Google); and no means IT service company will escape by providing at par solutions which adheres to current user expectations
SONA (Service Oriented Networking Architecture) is open standard, which nicely fits in between Business Architecture and Technology architecture. It provides in built networking services like faster IP routing, data cache, security etc. With the help of SONA enabled applications; with in CISCO, enterprise applications response through-put increased to ~ 40%.
It also observed that, any strategy should be on business centric rather than people or technology centric; to stay competitive in modern business environment.
CISCO adopted TOGAF – ADM as architectural framework while developing SONA.
Managing Change in EA Program
Mr.Ron Baillie of Cathay Pacific shared his practical experience when introducing the Enterprise architecture program with in IT team. Initially there was lots of resistance from internal IT team to understand and adapt new enterprise concepts. Mr.Ron introduced several EA program innovative concepts like;
Having all EA principle (there were 06 principle’s to start with) in a cube.
Arranged many programs to understand such concepts; including his CIO
He highlighted few observations which are come out during EA program execution;
Motivate the people respect to the context (like cost= total no of First class empty seats…)
There must be Centralized architectural artifacts
Identify the key principles in EA program
Create an ownership for each principle
Roadmaps should be created for each EA components
Associate business matter experts for each roadmap
Also he highlighted EA is a journey; not an end point. Following are few principle’s he adopted in Cathay Pacific:
Simplicity
Modularity
Standardization
Measurement
Life Cycle
Etc…
Finally there is very interesting presentation slide; which shows picture were all fishermen rowing the boat in one direction. In an analogy he stated; it is very important in EA program whether all stakeholders are rowing same direction or not.
Introduction to TOGAF
Mr.Vishwanthan of C&CC solutions; Australia (TOGAF certified) gave a nice presentation on TOGAF 8.1. Few things about TOGAF;
1. TOGAF is a framework; not a architecture
2. TOGAF certification is all about checking one’s knowledge about TOGAF; not a check on skills or related implementation. Holds very good acceptance from enterprise architect’s community
3. It’s customer initiative; not from Open group
4. It is defacto industry accepted architectural framework. It can be used in conjunction with many architectural frameworks like Zachman, DoDAF, MDA, FEAF etc
5. Zachman and TOGAF compliment each other. TOGAF shall be used as implementation framework for Zachman.
6. Already there are several mappings exists respect to TOGAF; mainly
a. Zachman
b. MDA
c. DoDAF
d. COBIT
e. ITIL
f. FEAP
TOGAF shall be certified in two ways;
§ Directly taking the exam from Prometric center
§ Or attending the training from Open group authorized training institution.
One can build a business case for TOGAF as EA; providing sufficient strengths like
Ability to chunk-up the whole enterprise architectural program into different ADM phases. Here each ADM phase may run into several iterations; depending on the organization’s business complexity.
Avoid the redundancy in process to building new project
Avoid the silo-ed approach.
TOGAF 8.1 divided into three parts;
ADM (Core implementation phases)
Enterprise Continuum (TRMs, Federated EA’s etc…)
Resource base (Case studies, Glossaries, Templates, Evaluations etc…)
Also he emphasized on ADM and its relative importance in overall EA implementation program.
ADM is an iterative method; consists of totally 8+1 phases. Also there is preliminary phase to start with
Each iteration; there will be new decisions. So each decision should have adequate information on
Overall enterprise coverage
Level of detail to understand the decision
Time horizon to implement the decision etc…
Every phase is validated against the business requirements
Any decision will be based on Competence (business) and resource availability
Jason Uppal from QuickResponse, Canada; gave excellent insight towards TOGAF 8.1 by going through ADM phases. Below are few thoughts:
Business Requirements
These are also called as “Architectural Requirements” are nothing but set of wish lists which enterprise have, but preventing for implementation. So these are actual architectural requirements. It might include wicked problems as well. Wicked problems are one which is very hard to frame.
Architecture Vision
In this phase, EA should attack the wicked problems, apply the SMART objectives and also come up the statement of architectural work. If Architecture vision is set right; then rest of phases more likely to succeed. It is very important that EA must gain confidence from all stake holders.
Business Architecture
While developing business architecture, following are few areas should be considered for effective impact on overall EA program:
Effective business process
Impact of change on people
Implementable business process (think “Realistic” principle of SMART!)
Data architecture
What information is required to make an effective business process?
Application architecture
Cost effective way to deliver information system to make business process efficient
Infrastructure
Hardware, Software, People are required to deliver services to meet required SLA
Opportunities and Solutions
Ideal set of objectives/Initiatives (Technology is limiting factor; people & process change etc are key challenges!)
Migration Planning
Set of initiatives required to deliver architectural vision.
Define Value
Organization learning towards expected benefits from EA program. Also value of exploring current enterprise capabilities
KPI Governance
Define, Measure and Report architectural changes. Also study the corrective action and impact analysis on already defined phases of ADM due to change.
Brief on SMART objectives
All businesses need to set objectives for themselves or for the products or services they are launching. What does your company, product or service hope to achieve? Setting objectives are important. It focuses the company on specific aims over a period of time and can motivate staff to meet the objectives set.
A simple acronym to set the objectives is called SMART objectives.
Specific – Objectives should specify what they want to achieve.Measurable – You should be able to measure whether you are meeting the objectives or not.Achievable - Are the objectives you set, achievable and attainable?Realistic – Can you realistically achieve the objectives with the resources you have?Time – When do you want to achieve the set objectives?
Difference between Zachman and TOGAF
Following are few differences;
TOGAF tells step by step implementation of each step is dependent on other, where in Zachman framework does not have the dependency
Operations feature is not included in TOGAF, but Zachman got detailed information.
Proposed TOGAF 9 focuses on Governance, Portfolio management etc.
Enterprise conceptual model
Mr.Gundars Osvalds from BearingPoint, USA, gave short presentation on conceptual model in EA. Enterprise architecture conceptual model contains following sections; these conceptual model elements are interlinked and will drive each other.
Framework
Architecture
Life History
View
View Point
Abstractions
Framework concept
Select one or more framework (Federated architectural approach!) to arrive EA.
Zachman
TOGAF
Framework
DoDAF
FEAF
Enterprise Architects can be developed
In interesting presentation Jason Uppal from QuickResponse, ITAC level-2; opened up a nice discussion on how to develop an Enterprise architect. Here are few ideas:
Start working with some strategy in mind. Strategy should have direction (like Financial, Customer supplier, Organization objectives etc…)
Perform the litmus test using SMART objectives
Identify the current constraints (Area not to focus on)
Have a Guidelines (Area to focus on)
Develop a programmatic roadmap (Benefits, Costs, Risks, Why you???) for a business strategy. Provide expertise based on leadership to help and execute the roadmap
Study architectural views on People, Process and Technology for Business Architecture, Data Architecture, Application Architecture and Infrastructure Architecture
He advised audience to concentrate on “Wicked Problems” of business
More wicked problems, higher level of effort is needed to come up with realistic EA.
In spot light forum discussions, Mr. Allen Brown, CEO of Open group gave insight towards few standards like;
“Interoperable Enterprise” - Look for white paper from http://www.opengroup.org/cio/iop/index.htm
He also highlighted the current problems in enterprise; mainly Cross functional team culture, new business partners and stove-piped information.
He also stressed on having “Bounderyless Information flow” with in enterprise. Finally he concluded discussion by saying “Requirement defects are very expensive” and worldwide nearly 53% of defects are raised from business requirement.
Subscribe to:
Posts (Atom)