Thursday, July 23, 2009

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

Thursday, July 16, 2009

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

Thursday, July 9, 2009

Book Review: 97 Things Every Software Architect Should Know Edited by Richard Monson-Haefel: Publisher- O'Reilly Media, Inc.: ISBN- 10: 059652269X

This book introduces new concept of book writing – Community Book. And to pleasure of Open Source supporters, book is available under Common Creative License.

Book consists of 97 aptly written essays about Software Architecture barring technical details but focused on Business and human behavior. Book does not mention any vendor and technology specific details which makes universally applicable. Unlike other Software Architecture books which are highly loaded with UML, patterns and other technical details this book covers practical day to day practices for software architecture.

97 Things Every Software Architect Should Know is crisp 200 pages long. Few of the participating authors are well known authority in software while some are hidden gems who yet to be discovered. Few of the authors have their own site and blog which will give insight into their work.

1 Allison Randal (The lead developer for Parrot)
2 Barry Hawkins
3 Bill de hÓra (Co-editor of Atom publishing protocol)
4 Brian Hart
5 Burk Hufnagel
6 Chad LaVigne
7 Clint Shank
8 Craig L Russell
9 Dan Chak
10 Dave Anderson
11 Dave Bartlett
12 Dave Muirhead
13 Dave Quick
14 David Ing
15 Doug Crawford
16 Eben Hewitt (Author of SOA Cookbook)
17 Edward Garson
18 Einar Landre
19 Eric Hawthorne
20 Erik Doernenburg
21 Evan Cofsky
22 George Malamidis
23 Greg Nyberg (author of the WebLogic companion workbook for Enterprise JavaBeans 3rd Edition and is the lead author of the book Mastering WebLogic Server )
24 Gregor Hope (Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions (Addison-Wesley Signature Series)
25 Jeremy Meyer
26 John Davies
27 Kamal Wickramanayake
28 Keith Braithwaite
29 Kevlin Henney (coauthor of two volumes in the Pattern-Oriented Software Architecture series: A Pattern Language for Distributed Computing and On Patterns and Pattern Languages)
30 Mark Ramm
31 Mark Richards
32 Michael Harmer
33 Michael Nygard (Release It!: Design and Deploy Production-Ready Software (Pragmatic Programmers))
34 Michael Nygard ( “Release It! Design and Deploy Production-Ready Software” - a 2008 Jolt Productivity Award Winner)
35 Mike Brown
36 Mncedisi Kasper
37 Neal Ford (Author of “The Productive Programmer”)
38 Niclas Nilsson
39 Nitin Borwankar
40 Norman Carnovale
41 Paul W. Homer
42 Peter Gillard-Moss
43 Philip Nelson
44 Randy Stafford
45 Rebecca Parsons (CTO of ThoughtWorks)
46 Richard Monson-Haefel
47 Sam Gardiner
48 Scot Mcphee
49 Stephen Jones
50 Timothy High
51 Udi Dahan
52 Vinayak Hegde
53 Yi Zhou
54 Zubin Wadia (Author of: "The Definitive Guide to Apache MyFaces & Facelets" and "Facelets Essentials: Guide to JavaServer Faces View Definition Framework")

In nutshell book spells out two vital things:

1. Role of a Software Architect
2. What should a Software Architect know apart from technical details?

In starting of book natural question come into mind that why 97, why not 96 or 98 but as you go along with book you do not care about its count. You can get details of why 97 at its site

97 Things Every Software Architect Should Know is already in bookshelf.

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:
1. The Architectural Journal (Microsoft) 15
2. www.bredemeyer.com/pdf_files/role.pdf
3. http://en.wikipedia.org/wiki/Software_architect

One can get more information about book and related topics from:

1. Book’s web presence
2. Amazon
3. Publisher – Oreilly
4. flipkart
5. Barnes & Noble
6. For Indian Customers
7. One More place for Indian Customers
8. Discussion at The Server Side
9. Review by Mark Needham
10. Review by Brian
11. Book Review at Dzone
12. Review at Meme Agora
13. One More Review
14. Another Review
15. The last one

Sunday, July 5, 2009

Standards ???

In IT industry whenever any one architect or design a system/product, few lines about standards are always said. It start with what are the standards are used in development and what standards system/product comply to. You see any data sheet offered by any vendor they boast about standards their offerings comply to. It seems that every body is obsessed with standards.

Does any body giving any thought that what these standards offers in terms of business and technical benefits?
Why there are so many standards (just look at web services)?
Who is offering these standards?
What are the motives of these standards?
Why there are so many vendors are complying with standards?
Are standards pushing us towards a single mold fit all?