Some cool agile experimentation
https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/
Sunday, 15 February 2015
Monday, 1 October 2012
What is new in TOGAF 9
Recently I completed my TOGAF 9 certification and was asked if I could present what is new in TOGAF 9. Following is a brief summary:
TOFAG 9 is the next evolution and not a “revolution” of the specification. There are no changes to the top level processes. There are stronger links to the business strategic planning and deployment decisions. It is easier to use due to its more formal meta model with more guidelines techniques and templates.
More specifically new subject areas in TOFAG 9 are:
Partitioning is used to divide work and can cover multiple levels of architecture. For example corporate EA capability team consisting of lead enterprise architect and chief architect can work on strategic architecture level. Portfolio team consisting of domain architects or stream leads within the domain can work on segment level architecture and project level teams within the domains and streams can work on capability level architecture.
How
Above can be achieved in two approaches within the ADM.
Multiple ADM cycles
Each level can be done by its own ADM cycle where the strategic ADM cycle in phase F triggers one or more ADM cycle’s for segment architecture’s and likewise, segment architecture phase F triggers one of more ADM cycles of capability architecture’s.
One ADM cycle
All levels can be done using one ADM cycle. Strategic architecture can be done in phase A Architecture Vision. Segment architecture can be completed in Phases B-D (Business, Information, and Technology) and capability architecture in phase E (Opportunities and Solutions)
Capability based planning sits horizontally across vertical functional business units. Enterprise Architecture is a very good fit for capability planning as it also sits horizontally across the business units.
Example set of factors:
Types of architectural assets and their relationships to the broader enterprise repository are depicted below:
Stakeholder can be grouped in the power grid and classified by the level of interest e.g. which stakeholders need to be kept satisfied, kept informed, who are the key players and which stakeholders require minimal effort to manage.
Security architecture:
Service Oriented Architecture tailors number of activities in the TOGAF ADM in order to meet SOA objectives. For example as part of the Preliminary and Architecture Vision phases it can:
For more in depth information on any of these subject areas see the TOGAF Open Group Standard specification http://pubs.opengroup.org/architecture/togaf9-doc/arch/
TOGAF
Evolution of TOGAF
TOGAF journey started in 1993 when customers started demanding architecture standards. In 94 DOD donated the TAFIM as a base and in 96 TOGAF specifications was first published. TOGA F7 technical edition was published in 2002 and TOGAF 8 in 2003. TOGAF 9 enterprise edition was first released in 2009.TOFAG 9 is the next evolution and not a “revolution” of the specification. There are no changes to the top level processes. There are stronger links to the business strategic planning and deployment decisions. It is easier to use due to its more formal meta model with more guidelines techniques and templates.
More specifically new subject areas in TOFAG 9 are:
- Architecture Partitioning
- Content Framework and meta model
- Capability Based planning
- Business transformation readiness
- Architecture repository
- Stakeholder management
- Security architecture
- SOA
Architecture Partitioning
Who and WhatPartitioning is used to divide work and can cover multiple levels of architecture. For example corporate EA capability team consisting of lead enterprise architect and chief architect can work on strategic architecture level. Portfolio team consisting of domain architects or stream leads within the domain can work on segment level architecture and project level teams within the domains and streams can work on capability level architecture.
How
Above can be achieved in two approaches within the ADM.
Multiple ADM cycles
Each level can be done by its own ADM cycle where the strategic ADM cycle in phase F triggers one or more ADM cycle’s for segment architecture’s and likewise, segment architecture phase F triggers one of more ADM cycles of capability architecture’s.
 |
| Multiple ADM Cycles |
One ADM cycle
All levels can be done using one ADM cycle. Strategic architecture can be done in phase A Architecture Vision. Segment architecture can be completed in Phases B-D (Business, Information, and Technology) and capability architecture in phase E (Opportunities and Solutions)
 |
| One ADM Cycle |
TOGAF 9 Content Framework and Meta Model
 |
| Content Meta Model |
Capability Based planning
Capability Based planning is a business planning technique that focuses on business outcomes. It consists of the planning, engineering and delivery of strategic business capability to an enterprise rather than a specific unit.Capability based planning sits horizontally across vertical functional business units. Enterprise Architecture is a very good fit for capability planning as it also sits horizontally across the business units.
Business Transformation Readiness Assessment
Evaluated and quantifies organisations readiness to undergo change. Most organisations will have their own unique set of factors and criteria, but most are similar.Example set of factors:
- Vision
- Desire
- Willingness
- Resolve
- Need
Architecture Repository
Architecture repository is an architecture part of the wider enterprise repository that manages different types of architectural assets that exist at the different level of abstraction.Types of architectural assets and their relationships to the broader enterprise repository are depicted below:
 |
| Architecture Repository |
Stakeholder Management
Stakeholder Management provides some useful guidelines on navigating the individual organisation politics and power brokers and how to best manage them.Stakeholder can be grouped in the power grid and classified by the level of interest e.g. which stakeholders need to be kept satisfied, kept informed, who are the key players and which stakeholders require minimal effort to manage.
Security Architecture
Security Architecture has its own discrete security methodology and is treated as a separate architecture domain within the enterprise architecture while needing to be fully integrated in it.Security architecture:
- composes its own discrete views and viewpoints
- addresses non-normative flows through systems and among applications
- introduces its own normative flows through systems and among applications
- introduces unique, single-purpose components in the design
- calls for its own unique set of skills and competencies of the enterprise and IT architects
SOA
SOA and EA are closely related as they address number of similar concerns for the business stakeholders. Both initiatives need to ensure that stakeholder community needs are met and that business and IT are linked in order to justify cost of IT reengineering against the business value.Service Oriented Architecture tailors number of activities in the TOGAF ADM in order to meet SOA objectives. For example as part of the Preliminary and Architecture Vision phases it can:
- adopt the principles of service orientation
- determine the organisational readiness for SOA
- adopt the open group SOA Governance model
- partition by utilising a specialist centre of excellence to support SOA
For more in depth information on any of these subject areas see the TOGAF Open Group Standard specification http://pubs.opengroup.org/architecture/togaf9-doc/arch/
References
Architecting the Enterprise TOGAF® 9 for Practitioners (Level 1 & 2) Course MaterialTOGAF
Friday, 2 December 2011
Soft skills and EA
Interesting short article on how/where “Architecture” fits within the business space.
http://www.architecting-the-enterprise.com/blog/2011/11/using-soft-skills-to-promote-architecture-to-the-business/
Scenario below is so common:
“Many Architects find themselves having little influence at the preliminary or vision phases of projects and are often brought into the development at a later stage; usually by the PMO. Unsurprisingly, the point of influence is weakened by this time as many of the key decisions have already been made and the Architect is left to play catch-up and may sometimes be viewed as a barrier by the Project Manager whose prime concern is timely delivery.”
And the statement:
“Most business leaders are concerned with only a small number of factors; usually: Risk, cost, time and return on investment, not necessarily in that order – are usually at the top concerns.”
Is also very accurate although I wish that return on investment becomes bigger priority then what I have seen in the past. Often business will choose cost, time over return on investment.
http://www.architecting-the-enterprise.com/blog/2011/11/using-soft-skills-to-promote-architecture-to-the-business/
Scenario below is so common:
“Many Architects find themselves having little influence at the preliminary or vision phases of projects and are often brought into the development at a later stage; usually by the PMO. Unsurprisingly, the point of influence is weakened by this time as many of the key decisions have already been made and the Architect is left to play catch-up and may sometimes be viewed as a barrier by the Project Manager whose prime concern is timely delivery.”
And the statement:
“Most business leaders are concerned with only a small number of factors; usually: Risk, cost, time and return on investment, not necessarily in that order – are usually at the top concerns.”
Is also very accurate although I wish that return on investment becomes bigger priority then what I have seen in the past. Often business will choose cost, time over return on investment.
Monday, 14 November 2011
WSO2 practical SOA workshop
Attended a WSO2 practical SOA workshop yesterday. It was quite good. Quick summary.
WS02 http://wso2.com is an open source middleware company. One of its main offerings is a product suite called WS02 Carbon which is conceptually similar to something like Oracle Fusion. It consists of number of individual middleware products such as ESB, Services Application Server, Business Process Server, Business Rules Server, Governance Registry etc…
One good thing about WS02 product suite is that is built from ground up, it is componentized and it’s well integrated. That is one of the advantages over other commercial offerings as lots of their individual products have been put together by acquisition and made (or forced) to work together.
I have had a bit of experience with middleware products from different vendors both commercial and open source such as Oracle Fusion suite (BPEL, ESB, Rules Engine, Mediator etc…), IBM (WebSpere ESB, WebSphere Process Server, Message Broker etc…), JBOSS (jBMP, ESB) and can confirm that open source offering such as WS02 are truly lean products compared to their commercial competition. Being open source based they are lean in development, methodology, delivery, governance as well as licensing. From my experience quality of the open source products is also generally higher. Less is more. To be fair commercial offerings often provide better tooling, training, documentation and support.
Number and calibre of WSO2 customers is also impressive. It consist of some globally recognised companies mostly in Europe and US (this seems to be the common trend for open source and WSO2 is currently working on creating a bigger footprint in Australia).
Workshop presenters were very knowledgeable and honest about SOA. They presented some real life industry examples of good and bad SOA implementations. Just because companies use the SOA middleware and know SOA theory does not mean they always know how to apply it correctly. Not entirely their fault as there could be number of constraints on their designs such as legacy, political, financial etc…. It comes down to basic principles of minimizing data dependencies, low coupling and using the right technology (middleware tool) for the given problem. Creating a “sane” granularity of the services, equally well balanced message model and separating the domain model from the message model. More coarse grained service and more abstract message model will produce more robust and stable service.
All in all, with complimentary pen, notebook, poster, lunch and coffee a day well spent!
WS02 http://wso2.com is an open source middleware company. One of its main offerings is a product suite called WS02 Carbon which is conceptually similar to something like Oracle Fusion. It consists of number of individual middleware products such as ESB, Services Application Server, Business Process Server, Business Rules Server, Governance Registry etc…
One good thing about WS02 product suite is that is built from ground up, it is componentized and it’s well integrated. That is one of the advantages over other commercial offerings as lots of their individual products have been put together by acquisition and made (or forced) to work together.
I have had a bit of experience with middleware products from different vendors both commercial and open source such as Oracle Fusion suite (BPEL, ESB, Rules Engine, Mediator etc…), IBM (WebSpere ESB, WebSphere Process Server, Message Broker etc…), JBOSS (jBMP, ESB) and can confirm that open source offering such as WS02 are truly lean products compared to their commercial competition. Being open source based they are lean in development, methodology, delivery, governance as well as licensing. From my experience quality of the open source products is also generally higher. Less is more. To be fair commercial offerings often provide better tooling, training, documentation and support.
Number and calibre of WSO2 customers is also impressive. It consist of some globally recognised companies mostly in Europe and US (this seems to be the common trend for open source and WSO2 is currently working on creating a bigger footprint in Australia).
Workshop presenters were very knowledgeable and honest about SOA. They presented some real life industry examples of good and bad SOA implementations. Just because companies use the SOA middleware and know SOA theory does not mean they always know how to apply it correctly. Not entirely their fault as there could be number of constraints on their designs such as legacy, political, financial etc…. It comes down to basic principles of minimizing data dependencies, low coupling and using the right technology (middleware tool) for the given problem. Creating a “sane” granularity of the services, equally well balanced message model and separating the domain model from the message model. More coarse grained service and more abstract message model will produce more robust and stable service.
All in all, with complimentary pen, notebook, poster, lunch and coffee a day well spent!
Tuesday, 9 August 2011
Web Portal
So what is a Web Portal? Like many terms in Technology world it is highly overloaded. In this blog I will try and give yet another (my view) on the Web Portal from my personal experiences.
When I think of a web portal I think of a framework for creating web applications. Depending on the vendor, this framework comes with number of different capabilities and tools out of the box and varying degrees of constraints to use these tools. For example it can come with web content management, work flow driven content management, dynamic customisation, dynamic personalisation, dynamic security, auditing, analytics, staging, performance monitoring, searching, ability to integrate other web app’s, ability to integrate with other enterprise app's via standard protocols such as JSR170, SOAP/HTTP, WSRP etc…
On top of the above mentioned capabilities portal vendor will also provide integration and or basic out of the box capability for the latest collaboration tools wikis, discussions, announcements, chats etc…
It comes with a lot of “free” stuff. But as we all know there is never a “free lunch”. There is always a trade-off and in this case it will be in the portal learning curve, added overhead (non-required features, memory, administration), some technical constraint (library dependencies, platform etc…) and possibly performance (again depends on the vendor). Every web application is different and each case will require business requirement analysis, technology investigation and justification of the decision to use or not use a portal for a particular web application.
Generally speaking portals will provide most benefits for:
So now you are ready to stand up a portal as pure content site, mash up site a wiki server, blog server, document library, collaboration server etc...
But what if you need custom functionality? Let’s look at some of the technology choices that need to be made.
Technology
Broadly speaking web applications run on a technology stack. Anything non trivial that needs more than a stand-alone web server will require a servlet container or an application server (on Java platform).
Technically, portal is a technology layer that sits in between one or many web apps (portal apps) and the application server. Portlet container sits on top of the servlet container and provides the interface to portlets. Portal administrator/developers can group any number of portlets into communities, spaces, custom app to create portal apps.
When there is a need to create custom functionality in the portals this is done by writing portlets. Portlets can be deployed locally (running in the portal container) or remotely (via WSRP protocol). Remote portlets are deployed on a Portlet producer (Portlet container) and are rendered on a Portlet consumer app.
Again depending on the vendor there are variations to this architecture. For example Oracle WebCenter Portal version 11G does not support local portlets, only remote. However WebCenter allows using ADF task flows in its “portal” web applications. Some more detail on ADF task flows vs portlets in Oracle Web Center can be found here.
Many existing web application development frameworks can be used to write portlets. Some of them work better than others and may or may not require a portlet “bridge”. Some vendors provide IDE wizards to make it easier to create different technology portlets e.g. Plain JSP portlet, Struts portlet, JSF portlet, ADF portlet, Spring portlet etc… When deciding on portlet technology, consult the portal vendor on their recommendation as some of the portlets technology will have some constraints on certain portals e.g. JSF 1.0 portlets on BEA WebLogic Portal or Rich Faces Portlets on earlier versions of Liferay Portal. Alternatively perform some comprehensive POT (proof of technology) spikes to ensure that chosen portal and portlet technology play nice.
So there is a lot to think about and decide, safe option follow vendor recommendation for tried and tested technology combination.
Portals can be powerful tools that can provide high return on investment for many companies but there are few gotchas to look out for. They can also be lots of fun for the techies. So if you decide to implement a portal, enjoy the ride and remember (as Lance Armstrong says) “It’s not about the bike”!
When I think of a web portal I think of a framework for creating web applications. Depending on the vendor, this framework comes with number of different capabilities and tools out of the box and varying degrees of constraints to use these tools. For example it can come with web content management, work flow driven content management, dynamic customisation, dynamic personalisation, dynamic security, auditing, analytics, staging, performance monitoring, searching, ability to integrate other web app’s, ability to integrate with other enterprise app's via standard protocols such as JSR170, SOAP/HTTP, WSRP etc…
On top of the above mentioned capabilities portal vendor will also provide integration and or basic out of the box capability for the latest collaboration tools wikis, discussions, announcements, chats etc…
It comes with a lot of “free” stuff. But as we all know there is never a “free lunch”. There is always a trade-off and in this case it will be in the portal learning curve, added overhead (non-required features, memory, administration), some technical constraint (library dependencies, platform etc…) and possibly performance (again depends on the vendor). Every web application is different and each case will require business requirement analysis, technology investigation and justification of the decision to use or not use a portal for a particular web application.
Generally speaking portals will provide most benefits for:
- Modular application development (using portlets)
- Applications requiring features that are provided out of the box by a portal (cms, templating, role based access, collaboration tools etc…)
- Applications that integrate other web or non-web applications and present common look and feel
So now you are ready to stand up a portal as pure content site, mash up site a wiki server, blog server, document library, collaboration server etc...
But what if you need custom functionality? Let’s look at some of the technology choices that need to be made.
Technology
Broadly speaking web applications run on a technology stack. Anything non trivial that needs more than a stand-alone web server will require a servlet container or an application server (on Java platform).
Technically, portal is a technology layer that sits in between one or many web apps (portal apps) and the application server. Portlet container sits on top of the servlet container and provides the interface to portlets. Portal administrator/developers can group any number of portlets into communities, spaces, custom app to create portal apps.
When there is a need to create custom functionality in the portals this is done by writing portlets. Portlets can be deployed locally (running in the portal container) or remotely (via WSRP protocol). Remote portlets are deployed on a Portlet producer (Portlet container) and are rendered on a Portlet consumer app.
Again depending on the vendor there are variations to this architecture. For example Oracle WebCenter Portal version 11G does not support local portlets, only remote. However WebCenter allows using ADF task flows in its “portal” web applications. Some more detail on ADF task flows vs portlets in Oracle Web Center can be found here.
Many existing web application development frameworks can be used to write portlets. Some of them work better than others and may or may not require a portlet “bridge”. Some vendors provide IDE wizards to make it easier to create different technology portlets e.g. Plain JSP portlet, Struts portlet, JSF portlet, ADF portlet, Spring portlet etc… When deciding on portlet technology, consult the portal vendor on their recommendation as some of the portlets technology will have some constraints on certain portals e.g. JSF 1.0 portlets on BEA WebLogic Portal or Rich Faces Portlets on earlier versions of Liferay Portal. Alternatively perform some comprehensive POT (proof of technology) spikes to ensure that chosen portal and portlet technology play nice.
So there is a lot to think about and decide, safe option follow vendor recommendation for tried and tested technology combination.
Portals can be powerful tools that can provide high return on investment for many companies but there are few gotchas to look out for. They can also be lots of fun for the techies. So if you decide to implement a portal, enjoy the ride and remember (as Lance Armstrong says) “It’s not about the bike”!
Subscribe to:
Posts (Atom)