Wednesday, September 28, 2011
Friday, September 16, 2011
Typical API Design Goals
1. Clear separation in Content and Transaction API
2. Call on URL must be separate for regular site and API site
3. API site must be divided into two – test and prod
4. API site must be clearly demarked - json, rest and soap (myapplication.com/api/json, myapplication.com /api/rest, myapplication.com /api/soap).
5. Throttling/Rate Limiting for API calls must consider following factors
a. Time of call
b. Number of records per call
c. Number of calls per second using a API key (free and well as paid)
d. Hits per method/function
e. Test or prod API site
f. Content and Transaction API
g. IP address
h. Geographic Location
i. Specific Key may have enhanced SLAs/priority
j. Developer or Enterprise Key
k. Class of Enterprise – Platinum, Gold, Silver
l. Class of developer – MahaGuru, Guru, GuruBhai
m. Read or Write Call
6. API vs normal site traffic prioritization
7. API response caching ( not now but as application grow this should be pluggable)
8. Provision of deprecation of API
9. Versioning of API
10. Full backward compatibility
11. SSL/TCL availability for critical data – password, payment, etc
12. The call from client may be synchronous but internally it must go to queue (logical) and the requests must be served as per throttling priority Example sfdc custom or enterprise WSDL
13. The outward call from myApplication.com must go to queue (logical) and then served synchronously to client (myApplication.com will make synchronous call). Messages remaining in queue will die after certain amount of time. This time is not configurable by API users but by admins of myApplication.com. Example salesforce outbound message
14. To access API each developer must register and must be given key which identifies him/her.
15. To access user (normal site user – API should supply user credentials in secure fashion – SSL). Usage of OAuth needs to be explored.
16. Developer Key will be deactivated if not used for certain period of time.
17. If certain key tries to break throttling. First give warning, then deactivate for certain period of time and then deactivate permanently. Three Strike rule.
18. Reporting
a. Track overall API performance
b. Track API performance for each operation
c. Track API performance by developer
d. Track API performance by specific developer customers
e. Track API performance by client IP
f. Report on API usage by individual developer
g. Report on API usage by developer group
h. Report on API usage by specific developer customers
i. Ability to generate reports in multiple (i.e., CSV, PDF and HMTL) formats
j. Ability to integrate with an existing enterprise reporting system
k. API throughput report
l. API routing failure report
m. API utilization report
n. API availability report
o. API usage report
p. API availability report
q. API methods report
r. API response times report
s. API backend latency report
19. Billing & Metering and API integration
a. Support for Developers account
b. Support for Developers’ customers
c. Ability to bill specific API feature/function
2. Call on URL must be separate for regular site and API site
3. API site must be divided into two – test and prod
4. API site must be clearly demarked - json, rest and soap (myapplication.com/api/json, myapplication.com /api/rest, myapplication.com /api/soap).
5. Throttling/Rate Limiting for API calls must consider following factors
a. Time of call
b. Number of records per call
c. Number of calls per second using a API key (free and well as paid)
d. Hits per method/function
e. Test or prod API site
f. Content and Transaction API
g. IP address
h. Geographic Location
i. Specific Key may have enhanced SLAs/priority
j. Developer or Enterprise Key
k. Class of Enterprise – Platinum, Gold, Silver
l. Class of developer – MahaGuru, Guru, GuruBhai
m. Read or Write Call
6. API vs normal site traffic prioritization
7. API response caching ( not now but as application grow this should be pluggable)
8. Provision of deprecation of API
9. Versioning of API
10. Full backward compatibility
11. SSL/TCL availability for critical data – password, payment, etc
12. The call from client may be synchronous but internally it must go to queue (logical) and the requests must be served as per throttling priority Example sfdc custom or enterprise WSDL
13. The outward call from myApplication.com must go to queue (logical) and then served synchronously to client (myApplication.com will make synchronous call). Messages remaining in queue will die after certain amount of time. This time is not configurable by API users but by admins of myApplication.com. Example salesforce outbound message
14. To access API each developer must register and must be given key which identifies him/her.
15. To access user (normal site user – API should supply user credentials in secure fashion – SSL). Usage of OAuth needs to be explored.
16. Developer Key will be deactivated if not used for certain period of time.
17. If certain key tries to break throttling. First give warning, then deactivate for certain period of time and then deactivate permanently. Three Strike rule.
18. Reporting
a. Track overall API performance
b. Track API performance for each operation
c. Track API performance by developer
d. Track API performance by specific developer customers
e. Track API performance by client IP
f. Report on API usage by individual developer
g. Report on API usage by developer group
h. Report on API usage by specific developer customers
i. Ability to generate reports in multiple (i.e., CSV, PDF and HMTL) formats
j. Ability to integrate with an existing enterprise reporting system
k. API throughput report
l. API routing failure report
m. API utilization report
n. API availability report
o. API usage report
p. API availability report
q. API methods report
r. API response times report
s. API backend latency report
19. Billing & Metering and API integration
a. Support for Developers account
b. Support for Developers’ customers
c. Ability to bill specific API feature/function
Thursday, September 15, 2011
How to achieve Business Goals
1. Prepare API strategy which cater to developers in comprehensive fashion
a. Open API
b. Separation of Content & Transaction API
c. Major part of API should be free
d. Thorough but easy and efficient developer registration process
e. Developers should be able to showcase their work
f. Developer should be able to discuss and share issues/challenges (forum)
g. Comprehensive documentation (developers manual) – pdf book as well as Wiki
h. Over the time period 3rd party developers should be major contributor to API management.
i. Some mechanism like Java Bug Parade
j. Involve developers in documentation translation
k. Distribute small projects – tool specific like – SOAP UI, Sahi, etc
2. API must be marketed at/via
a. Company microsite at facebook, linkedin, twitter
b. API documentation – manual & presentations must be available at webapplication/platform, document repositories – scribd, slideshare, desi forums, etc
c. Sample applications must be available at mobile application development sites – android, iPhone, iPad, HTML5, etc
d. Sample application must be available at Webservices sites – java, c#, scala, .net, php, etc
e. API details must be available at programmableweb.com and other similar sites
f. Conduct competition for innovative, most traffic generated web application
g. Pay application developer if that application develop uses paid API and generate certain amount of traffic over a time period.
3. No differentiation on the basis of end product (developed by 3rd party) licensing regime.
4. Developer portal
a. Discussion forum
b. Documentation
c. Bug Parade
d. Gamification ( Badge, enhanced role in management of API, etc)
e. Facility to showcase developers’ work
f. Enterprise and individual accounts
Wednesday, September 14, 2011
API Business Goals
1. Develop mobile applications, MS office plugins etc
2. Spur the 3rd party application development which can drive traffic and hence usage of web application/platform
3. Use it as marketing tool for developers
4. Collect analytic to design future strategy for platform/web application
5. Data collection about developers which can be utilized in future.
Monday, September 12, 2011
Book Review: Codermetrics Analytics for Improving Software Teams
Book Review: Codermetrics Analytics for Improving Software Teams by Jonathan Alexander: Publisher- O'Reilly: ISBN- 13: 978-1449305154
Codermetrics is the first book which takes the benefit of research and understanding in the area of professional sports and brings into software development.
This book is heavily influenced by Moneyball (http://en.wikipedia.org/wiki/Moneyball) and The Blind Side (http://en.wikipedia.org/wiki/The_Blind_Side:_Evolution_of_a_Game) by Michael Lewis (http://en.wikipedia.org/wiki/Michael_Lewis_%28author%29).
This book is segmented into three parts. Part one: Concepts covers basics of coder related metrics and how and why the affect big picture of software development. Part two: Metrics lists various metrics developed by author for coders/developers and third part Processes explains how system to be developed to measure metrics developed in book.
As the name suggest this book is solely focused on coders/developers but if metrics developed in this book need to be successful then similar metrics need to be developed for other stakeholders of SDLC – like testers, support and maintenance developers, and business analyst.
Book is good attempt in exploring brand new area of software development and bringing in the learning’s from professional sports, it lacks in articulating few of the assumptions made while defining metrics. For example Chapter 4: Skill Metrics assumes that all tasks are of same size. And if tasks are of not same size then several of metrics needs re-definition. Also Chapter 5: Response Metrics has assumed that all software development is product related but reality is far from this.
Book is silent on statistical analysis of metrics. At most book does trend analysis which is very simplistic approach.
Though the ideas articulated by books seems to have very high potential and may get with agile very well but requires deep revision.
Disclaimer: I did not get paid to review this book, and I do not stand to gain anything if you buy the book. I have no relationship with the publisher or the author.
Further reading: This is the first book on the subject. I am not able find any book on the subject.
One can get more information about book and related topics from:
1. Book’s web presence http://codermetrics.org/
2. Amazon: http://www.amazon.com/Codermetrics-Analytics-Improving-Software-Teams/dp/1449305156/
3. Publisher – O’Reilly http://shop.oreilly.com/product/0636920020134.do
4. Review: http://startier.wordpress.com/2011/08/25/codermetrics/
Codermetrics is the first book which takes the benefit of research and understanding in the area of professional sports and brings into software development.
This book is heavily influenced by Moneyball (http://en.wikipedia.org/wiki/Moneyball) and The Blind Side (http://en.wikipedia.org/wiki/The_Blind_Side:_Evolution_of_a_Game) by Michael Lewis (http://en.wikipedia.org/wiki/Michael_Lewis_%28author%29).
This book is segmented into three parts. Part one: Concepts covers basics of coder related metrics and how and why the affect big picture of software development. Part two: Metrics lists various metrics developed by author for coders/developers and third part Processes explains how system to be developed to measure metrics developed in book.
As the name suggest this book is solely focused on coders/developers but if metrics developed in this book need to be successful then similar metrics need to be developed for other stakeholders of SDLC – like testers, support and maintenance developers, and business analyst.
Book is good attempt in exploring brand new area of software development and bringing in the learning’s from professional sports, it lacks in articulating few of the assumptions made while defining metrics. For example Chapter 4: Skill Metrics assumes that all tasks are of same size. And if tasks are of not same size then several of metrics needs re-definition. Also Chapter 5: Response Metrics has assumed that all software development is product related but reality is far from this.
Book is silent on statistical analysis of metrics. At most book does trend analysis which is very simplistic approach.
Though the ideas articulated by books seems to have very high potential and may get with agile very well but requires deep revision.
Disclaimer: I did not get paid to review this book, and I do not stand to gain anything if you buy the book. I have no relationship with the publisher or the author.
Further reading: This is the first book on the subject. I am not able find any book on the subject.
One can get more information about book and related topics from:
1. Book’s web presence http://codermetrics.org/
2. Amazon: http://www.amazon.com/Codermetrics-Analytics-Improving-Software-Teams/dp/1449305156/
3. Publisher – O’Reilly http://shop.oreilly.com/product/0636920020134.do
4. Review: http://startier.wordpress.com/2011/08/25/codermetrics/
Friday, September 9, 2011
Book Review: The Art of Managing Professional Services
Book Review: The Art of Managing Professional Services by Maureen Broderick: Publisher- Prentice Hall: ISBN- 13: 978-0-13-704252-4
It is very difficult to find a good book on Professional services but The Art of managing Professional Services by Maureen Broderick fills that gap very efficiently and effectively.
This book covers diverse facets of professional services in very precise and concise fashion which makes is must read for leaders in Professional Services.
Book beautifully covers practices employed by variety of Professional services and then set best practices. Book is divided into eleven chapters.
1. Professional Services
2. Shared Vision, Values, and Culture
3. People
4. Portfolio
5. Services
6. Finance
7. Positioning
8. Partnership
9. Strategy
10. Structure
11. Style of Leadership
Each chapter focuses on one topic and details on that.
As I always look for improvements, this book also needs few. Book is very much focusing on USA based PS organization which totally ignores rest of world’s reality. Secondly book does not include any big player from software services.
Nevertheless, book presents good over view of PS and certainly it will be in my book shelf.
Disclaimer: I did not get paid to review this book, and I do not stand to gain anything if you buy the book. I have no relationship with the publisher or the author.
Further reading: A competing book is Managing The Professional Service Firm by David H. Maister at http://www.amazon.com/Managing-Professional-Service-David-Maister/dp/0684834316 and Building Professional Services: The Sirens' Song (Harris Kern's Enterprise Computing Institute Series) by Thomas Lah ,Steve O'Connor, and Mitchel Peterson at http://www.amazon.com/Building-Professional-Services-Enterprise-Computing/dp/0132762102.
One can get more information about book and related topics from:
1. Book’s web presence http://www.theartofmanagingprofessionalservices.com
2. Amazon: http://www.amazon.com/Art-Managing-Professional-Services-Insights/dp/0137042523
3. InformIT: http://www.informit.com/articles/article.aspx?p=1667484
It is very difficult to find a good book on Professional services but The Art of managing Professional Services by Maureen Broderick fills that gap very efficiently and effectively.
This book covers diverse facets of professional services in very precise and concise fashion which makes is must read for leaders in Professional Services.
Book beautifully covers practices employed by variety of Professional services and then set best practices. Book is divided into eleven chapters.
1. Professional Services
2. Shared Vision, Values, and Culture
3. People
4. Portfolio
5. Services
6. Finance
7. Positioning
8. Partnership
9. Strategy
10. Structure
11. Style of Leadership
Each chapter focuses on one topic and details on that.
As I always look for improvements, this book also needs few. Book is very much focusing on USA based PS organization which totally ignores rest of world’s reality. Secondly book does not include any big player from software services.
Nevertheless, book presents good over view of PS and certainly it will be in my book shelf.
Disclaimer: I did not get paid to review this book, and I do not stand to gain anything if you buy the book. I have no relationship with the publisher or the author.
Further reading: A competing book is Managing The Professional Service Firm by David H. Maister at http://www.amazon.com/Managing-Professional-Service-David-Maister/dp/0684834316 and Building Professional Services: The Sirens' Song (Harris Kern's Enterprise Computing Institute Series) by Thomas Lah ,Steve O'Connor, and Mitchel Peterson at http://www.amazon.com/Building-Professional-Services-Enterprise-Computing/dp/0132762102.
One can get more information about book and related topics from:
1. Book’s web presence http://www.theartofmanagingprofessionalservices.com
2. Amazon: http://www.amazon.com/Art-Managing-Professional-Services-Insights/dp/0137042523
3. InformIT: http://www.informit.com/articles/article.aspx?p=1667484
Subscribe to:
Posts (Atom)
Posts
