Mike The Architect

Book Review: Troux Enterprise Architecture Solutions

I recently picked up a copy of Troux Enterprise Architecture Solutions by Richard Reese. I have worked with Troux in a variety of capacities in the past along with stacking them up with the other large Enterprise Architecture Tool vendors. I was naturally interested to see what guidance they have outside of the guidance used to operate and support the actual tool.

I was really surprised by the book as it went in a different direction than I thought it would. I expected the book to be largely about the tool. Using the tool as a lead in to the other Enterprise Architecture topics. This wasn't the case at all but rather the complete opposite. Those aspects were pleasant to see.

I have mixed reactions about the book. Just like with everything there are he good and bad aspects. Below are those aspects that I was able to distill out of the book.

The Good

• Practical Models - I really like when authors use real world examples. Obviously there are limitations to this from an IP perspective, however to show how these abstract concepts in  relatable scenarios that the reader would run across is extremely important.
• Right level of Theory and Practice - The book isn't too abstract as EA can get sometimes. There is a theme of practicality to the book.
• Visualizations - the chapter on visualizations was really drove the point home. It gave the reader a view into the tangible capabilities of Troux. There should be more of this in the book. My only negative here is that I wish the author would of gone into more details on the methods and processes that support these visuals. My fear would be that people would use these out of context. It would of been good to have more chapters like this one with rich visuals.
• TOGAF Alignment - Overall this chapter was good as well it provided a good overview and touched how Troux addressed TOGAF. I would however would of liked to see on a feature to process alignment matrix to show how much coverage Troux had on the tool.

The Bad

• Message and Purpose Diluted - I know this may seem fairly harsh, but I found the book to jump around quite a bit. There was a real flow issue with the book content. An example of this is Chapter 5 where organizational models are gone into depth while other chapters such as Metadata, business values or business alignment are either briefly covered or partially covered. After I read the book I wasn't able to takeaway a key message or theme that the author was trying to drive. This led to more questions than answers. That may of been the intent but it would of been setup for the expectation early in the book as I didn't walk away with "Troux Enterprise Architecture Solutions".
• High Level - This contradicts a positive point, I know, but the book was detailed in some areas and extremely vague in others. I think this is what really hurts the book.
• Transformation Platform Architecture - I was really surprised by this chapter. I was expecting more on how to make a platform like Troux scalable functionally along with key patterns to enabling Troux as the EA Knowledge Management tool. However, this chapter doesn't use the same principles that are described to model architectures and doesn't illustrate the architecture of the Troux solution very well. It would be good to see the same models and methods used for LOB applications used to decompose Troux platform to drive the message home.
• Metadata Management - This chapter went from theory directly into technical configuration really fast. While I really liked the trade-offs between centralized vs. decentralized repositories, I was expecting more tangible examples for the readers on the value and uses of metadata management, architecture Ontologies and Taxonomy and the impacts of social computing on how metadata can be enriched. This could of led to a great set of visuals, use cases, examples of kinds of metadata, formats, key lessons learned and how Troux could make metadata much more manageable and ultimately much more usable.
• Business Alignment - This chapter was all over the place. There was only one example of alignment and it was from a relatively unknown company. If there was a few companies that could be used as the basis for the methods it would of made this chapter so much better. However without real statistics, business process improvement or value realization metrics this chapter didn't convince me as a reader.
• Governance - This chapter only focused on standards and the tool. There was no mention of process or people. This is only a very, very small aspect of governance. The organizational structures while fictitious, is a bit misleading as most organizations have a variety of different structures. Finally there was no mention of organizational readiness or maturity that will ultimately drive the activities in which architects establish.
• Generating Business Value - This chapter was all over the place and was extremely high level. Not a whole lot of value gotten. I found most of the techniques mentioned were out of date with the industry. I was surprised by the RAD comments as this term is really outdated. Agile methods have surpassed RAD and have tangibly demonstrated its value. Why Agile methods are not mentioned was concerning as this is the world today not waterfall or RAD. I expected that to be addressed along with how it fits into EA or Troux.

In summary, the book was a bit of a let down for experienced Enterprise Architects but could be useful as a primer of EA's getting into the role that their company uses Troux. Even in that case this book should be supplemented with another set of resources to balance out the details.

Regardless, check out the book for yourself as there is a wealth of visuals that can stimulate you to think about how to make better IT decisions and to better position the value of EA.

Forrester: Mapping out Your Organizations Road to SharePoint Success Session

This was a great session that talked more about setting the expectation of what SharePoint really is, a Application Services Platform.

Great quote:

There isn’t one role but it takes a “village” of people to make it happen.

 

Making SharePoint Implementations Successful

In the presentation he went through the many roles it takes to successfully deploy a SharePoint platform. Thus, you must organize to capitalize. Below are the key roles needed:

1. Operations Manager
2. Solutions Architect (This is more of an EA role)
3. Network Analyst
4. Security Analyst
5. Librarian and records manager (I think of this more as an Information Architect)
6. Human Factors / UI Designer (I would call this UX Engineer or User Experience Designer)
7. Community Leader
8. Application Architect (Deep architect resource that know the bolts of SharePoint very well)
9. Collaboration Manager
10. Other IT Roles

 

Technorati Tags: SharePoint,Goverance

Non-Technical Factors that Lead to Poor Architectures

It is easy for us architects to think that we control the architecture design in it's entirety. But the sad truth is that there are too many dependencies for it to be just in our control. Architecture is more than just the technical side of things. A large part of it hinders on the business problem we are trying to solve and how palatable the solution is to the end users and the IT staff. This also includes working through processes to derive to the right decisions. 

Dependencies in the non-technical areas effects nearly every area of the architecture process as they drive how the solution is created. There are a number of processes that we should consider that are direct dependents of the architecture process. To name a few: project lifecycle (PLC), software development lifecycle (SDLC) and the many governance processes. 

There are some very common challenges that we see repeatedly. These include:

• Lack of Business Case - The business case really tells us the direction in which we should be going. It eludes to scope of the project. But what is so critical about it is the rationalization of the end value of the solution. This will give architects critical information to drive the solution. With this context defined we can better gauge how to align with the organizations principles, policies and standards that will expedite the project but most importantly it will leverage assets that have been defined as aligned with the strategic imperatives of the company. 
• Poor Project Management - This combines much of the scoping, resource allocation, roles and responsibilities, project structure (program vs. project vs. a series of activities), sponsor buy-in of the project management discipline. To keep things simple and since they are all interrelated I'm consolidating into approach. The core of the issue here is that if we have no approach framework to work within then how can we ensure that the right resources are looking at the problem or that in fact we are looking at the right problems. If we fail here, how do we know what are the value add areas we need to architect or validation of the design. How can we derive to the right decisions with our any if this? The answer is that we can not.  
• Disconnected Activities - I am not necessarily think about project plans and milestones but more in line with how major activities string together. Meaning are we doing design work before requirements or specifically in design how do we come to iterative decisions on architecture cross cutting concerns such as the physical architecture and the logical architecture. What comes first? Will these be final the first time? etc. Obviously this should be clearly defined in the SDLC. However this often times is not. 
• Ad-hoc Decision Making - All of the previous bullets really lead into this, informed decision making. As architects we need to have enough information to make informed decisions. If we do not, the end solution will not be the right one. 

To validate this thinking a bit more, Gartner put together a survey in 2007 that asked these very same questions. Below are the responses from CIO's in the government sector that were ask what where the top contributors to failure in their projects. As you can see there are a lot of commonalities here. While the government sector has specific challenges, this does resonate with what we see across industries. 

 

Source: Gartner - From the CIO Trenches, Why some project fail and other succeed. 

This analysis is very interesting as it points out some obvious points but also gives us some insight into how much these factors really play in. For example, lack of governance. I like to see governance pointed out when looking at project success and failures. What it shows us that if we don't have good controls, check points, processes and enterprise reference models than it impacts our ability to deliver projects.

This means that architects are responsible for ensuring that these enterprise processes are followed and adhered to. Keep in mind this doesn't mean that we become project managers or IT application or services owners, but rather knowing when the necessary steps haven't been taken, flagging them as risks and raising visibly when needed. 

This will ensure a quality solution because we can safely say that all the right questions were addressed and all the necessary stakeholders have had the the right information to make an informed decision. 

A funny example of Governance

I was forwarded this and had to share with all of you as this is absolutely hilarious.

Governance For Your OBA's

In last weeks session I was asked about governance and OBAs (at least from a server side perspective). I am happy to report that the community is concerned with governance as well. Microsoft IT Team Site Life Cycle Management Beta 1 was created on Codeplex and is intended to provide governance and manageability samples and tools designed to help IT Professionals management SharePoint Products and Technologies deployments. 

Upcoming tools include an implementation of site/web lifecycle management based on the Site Delete and Confirmation feature, the Microsoft IT Site Delete Capture 1.0 feature, and additional out-of-the-box functionality.  A sample auditing configuration solution deployment package will be introduced in the September-October timeframe that provides guidance on auditing and the management of content types across site collections.

Check out some of more governance content:

SharePoint Technology Governance Information on TechNet

SharePoint Governance posts on Joel's Blog

Manageability and Governance Post

Key Governance Considerations

Information Policies and Auditing Post

Information Architecture Post

Logical Architecture Samples

 

Tags: OBA