Recently, we have been talking about creating a single repository for IT Services departmental information. The idea being that our team members need to go to one place to get the information they are looking for. Instead of wasting time looking at multiple repositories each with their own taxonomies, UX and search features, put it all in one place with one UX and taxonomy.
Today, my thinking took a 180 degree turn with a vendor presentation on “enterprise search“. Instead of making people conform to rigid rules about where to put information, what if we gave them a tool to find the data wherever it resides behind our firewalls? Like someone said today, “Google search for our stuff”
No some of you might say, not taking time to architect an information repository and relying on a search engine is the lazy way out. I have some thoughts that I hope will make you think otherwise. When presented with business challenges, I find it is rarely the technology that is the problem. Instead, it is the ease of use for our clients, customers and stakeholders that should be considered. Enforcing compliance is expensive and in many cases ineffective. What if we made it easy for people to comply? Educate them on some simple tagging and then let them work like they always have. The difference is giving them a tool to search for what they need and work to tune that tool so that we see a significant reduction is costly “Search and not find” scenarios. Read more...
Alan Inglis posted about What good looks like from a solutions architecture perspective. How do you create a solution for a new project without creating architecture that already exists or making the same mistakes that previous projects made? This is a must read post and I recommend it.
Alan described 10 artefacts that he would expect a solutions architect to leave behind from a project implementation. They are:
- Project Background
- Terminology
- Key Drivers, Principles, Standards and Constraints
- Business Problem
- Information View
- Risk View
- Application View
- Data View
- Integration View
- Infrastructure View
I have some questions for Alan on this:
- How big a project would require this level of artefact creation? For small and possibly medium projects, the work to do the architecture may be more than delivering the project.
- Is there a subset of these artefacts that would be sufficient for small and medium projects?
- How would the next solutions architect find and assess the artefacts created? Need a searchable, secured repository – wiki?, blog?, SharePoint?, network file share?, knowledge base?
We, Enterprise Architects, regular trumpet the value of having an archictecture and learning from it. Some of the key factors for me would be: Read more...
I have been following Todd Biske ( @toddbiske) for a few years now. I was in Orlando in Oct 2008 teaching a full day course on EA in Higher Education at the Annual Educause 2008 conference and I met Mike Kavis ( @madgreek65) for lunch (via Twitter but that is another story). We talked about a bunch of EA and SOA things and he recommended Todd’s book – SOA Governance. One thing lead to another and I did not get a chance to order it until Jan 2009. Just finished reading it and found it to be an excellent start for the SOA initiative that we will be launching.
Over the past couple of years, we have made small attempts at SOA by building a few services to expose ERP functionality to our public web properties. After some discussion with our EA Solutions Council, we made an architectural decision to move away from our public web making direct calls to our backend ERP database and instead provision standards based services. Now that we will begin focusing on a formal SOA adoption strategy and I plan on leveraging Todd’s book to help us move forward and potentially avoid some of the pitfalls. Read more...
JP Rangaswami posted an interesting entry on Build versus Buy versus Opensource. In it he states:
“And the way I think of it is this:
For common problems use Opensource.
For rare problems use Buy.
For unique problems use Build. ”
Not bad but I really think he missed a fundamental part of this discussion. Reuse should always come first. Look at what you have in people and their skills and technology already deployed that could deliver the solution. I think my post on EA Guiding Principles better addresses the need for reuse.
Thoughts?