Edmonton CIPS Conference Day Two 7Nov2006
I apologize for being late with this instalment but it appears I have a real job with actual deadlines so writing a BLOG ends up lower on my priority list. Go figure? For this very same reason, my ranting will be short and to the point. Lucky you!
Session 1 Role of an Enterprise Architect
Architect delivering this ‘course’ was well spoken and I gleaned a few lessons learned from the material. Here it is in point form.
.TOGAF – This methodology was mentioned yet again as a reference point for architecture.
.Level 1 and Level 2 OMG Architect Certification is recommended. I agree and I intend on reviewing the course material and certification requirements before I pass judgement. But, on the surface, it sounds good and I can vouch for the credibility of the organization overall. They are part of the Integration Consortium and the representatives that I have met and the material on their site is first rate.
.Roles for the Architect include:
- Take responsibility
- Put your own credibility on the line
- Risk not Assumption so you get a mitigation plan and try to avoid blame game
- 2 week revisions on Architecture deliverables – refactoring essential
- Make people feel smart
- VISION, ROADMAP, EXECUTION
- Empower and step back to let others shine by supporting them 110%
- Know who has the Power and make them look good or make them feel/look smart
.Concerns and Questions from The SOA Integration Ninja
- Agility of the Options/Recommendations approach must be emphasize3d. Always expects change
- UML Standards for modeling were not emphasized. I think they should be
- The Zachman Framework was not brought up and I believe this deserves more emphasis as a resource for Enterprise Architects. Balance this methodology with TOGAF and with what the client wants and understands. Bingo – you are thinking outside the box.
- I am always frightened that the role of an architect changes into a justifier of change orders when the project is funded through a Fixed Price model.
Slides are available for this architecture presentation on the ice conference website. I would encourage aspiring integration consultants to understand and consider working towards a role as an Enterprise Architect.
Session 2 (My Work, Not the Conference Stuff)
I find myself in my hotel room working on a Service Design Process Model for a client. I will return to the Conference for a social event this evening and return home tomorrow morning. I discovered/designed a sublime method of providing Service Contract metadata with policy assertions, that I would love to share with you. Now, this is based on a design pattern that was proposed for the Provincial Health Integration Engine (Hub). This design included a service management front end with Oracle data structures that represent the metadata that would influence the runtime behaviour of services (parameters). Instead of this approach, which involves the creation of a front end administration module and a set of data structures, my more modest clients have turned to XML Schemas to define the contract/policy metadata. As an XML instance, the management can be through any XML aware admin console, even stooping to using IE Web Browser (read notepad) or some utility (preferably with Stylesheet support) that provides security administration capabilities with XML Schema editing.
The approach centers around the design of a contract XML Instance for every business service that is created and deployed. As the service runs, it uses the attributes on the instance to stamp the context for the event messages with the information maintained within this service contract. This occurs as the first step in a service process orchestration. After which, the service needs no further knowledge from the requestor or producer of the event since that context is provided through the contract (physically though the XML Instance).
Anyway, it seems much more important in my head as a design concept that it does as a revelation on paper. It deserves more respect and so I may write more in an upcoming whitepaper I am currently writing for the May 2007 Integration Consortium Summit(s). If you would like to write a paper, the call is open with details on their website.
“When there is no justice, the Ninja appear. They are not called to action by anyone.
They are just ordinary people in extraordinary situations. They need not have a clan or
credentials, or even a great deal of training. They only need the Will. The Ninja do what must be done.”
Ashida Kim, Secrets of the Ninja, DOJO Press 2000
Get IT done.
The SOA Integration Ninja
Session 1 Role of an Enterprise Architect
Architect delivering this ‘course’ was well spoken and I gleaned a few lessons learned from the material. Here it is in point form.
.TOGAF – This methodology was mentioned yet again as a reference point for architecture.
.Level 1 and Level 2 OMG Architect Certification is recommended. I agree and I intend on reviewing the course material and certification requirements before I pass judgement. But, on the surface, it sounds good and I can vouch for the credibility of the organization overall. They are part of the Integration Consortium and the representatives that I have met and the material on their site is first rate.
.Roles for the Architect include:
- Take responsibility
- Put your own credibility on the line
- Risk not Assumption so you get a mitigation plan and try to avoid blame game
- 2 week revisions on Architecture deliverables – refactoring essential
- Make people feel smart
- VISION, ROADMAP, EXECUTION
- Empower and step back to let others shine by supporting them 110%
- Know who has the Power and make them look good or make them feel/look smart
.Concerns and Questions from The SOA Integration Ninja
- Agility of the Options/Recommendations approach must be emphasize3d. Always expects change
- UML Standards for modeling were not emphasized. I think they should be
- The Zachman Framework was not brought up and I believe this deserves more emphasis as a resource for Enterprise Architects. Balance this methodology with TOGAF and with what the client wants and understands. Bingo – you are thinking outside the box.
- I am always frightened that the role of an architect changes into a justifier of change orders when the project is funded through a Fixed Price model.
Slides are available for this architecture presentation on the ice conference website. I would encourage aspiring integration consultants to understand and consider working towards a role as an Enterprise Architect.
Session 2 (My Work, Not the Conference Stuff)
I find myself in my hotel room working on a Service Design Process Model for a client. I will return to the Conference for a social event this evening and return home tomorrow morning. I discovered/designed a sublime method of providing Service Contract metadata with policy assertions, that I would love to share with you. Now, this is based on a design pattern that was proposed for the Provincial Health Integration Engine (Hub). This design included a service management front end with Oracle data structures that represent the metadata that would influence the runtime behaviour of services (parameters). Instead of this approach, which involves the creation of a front end administration module and a set of data structures, my more modest clients have turned to XML Schemas to define the contract/policy metadata. As an XML instance, the management can be through any XML aware admin console, even stooping to using IE Web Browser (read notepad) or some utility (preferably with Stylesheet support) that provides security administration capabilities with XML Schema editing.
The approach centers around the design of a contract XML Instance for every business service that is created and deployed. As the service runs, it uses the attributes on the instance to stamp the context for the event messages with the information maintained within this service contract. This occurs as the first step in a service process orchestration. After which, the service needs no further knowledge from the requestor or producer of the event since that context is provided through the contract (physically though the XML Instance).
Anyway, it seems much more important in my head as a design concept that it does as a revelation on paper. It deserves more respect and so I may write more in an upcoming whitepaper I am currently writing for the May 2007 Integration Consortium Summit(s). If you would like to write a paper, the call is open with details on their website.
“When there is no justice, the Ninja appear. They are not called to action by anyone.
They are just ordinary people in extraordinary situations. They need not have a clan or
credentials, or even a great deal of training. They only need the Will. The Ninja do what must be done.”
Ashida Kim, Secrets of the Ninja, DOJO Press 2000
Get IT done.
The SOA Integration Ninja
posted by Murray Laatsch at 8:23 AM
0 Comments:
Post a Comment
<< Home