/* Google Analytics ----------------------------------------------- */

Monday, July 20, 2009

End User Performance Mgt - More client Tool

It seems that everybody wants to release its own browser plug-in or tool for end user client performance management.

My Space MSFast

MSFast is a browser plug-in that help developers to improve their code performance by capturing and measuring possible bottlenecks on their web pages. MSFast currently supports only Internet Explorer 6 and up.
  • Measure the CPU hit and memory footprint of your pages as they render on the client’s browser
  • Review screen shots of the page while it renders
  • Review the rendered HTML on each point of the page’s lifecycle
  • Measure and show estimates of the time it takes to render each section of the page in different connection speeds
  • Validate the content of your page against a set of proven “best practice” rules of web development
  • Review downloaded files and show download time estimation on different bandwidths

Sunday, July 19, 2009

To ESB or not ESB

Reading this post from the crator of Mule, I could not agree more. In my team we had so many discussions about what is an ESB and if our current Tibco BusinessWorks platform is an ESB or not.
The main issue I face is always the same. I had to face it when doing integration with SAP and having to fight with SAP team to make them use Tibco BusinessWorks and SAP adaptor instead of SAP build-in point to point solution (that was before netweaver).

How can you justify an ESB to a team that was managing its own world for years. They were used of being a master data source and they know that all messages will have to go to them first, before being published to other systems. So why do you need an ESB? Just send them the XML they want (they are the king), no need to route the message. Direct connection. Point to point.

You can try any possible sound explanations, at the end, it is always: my solution works, this solution is not expensive (people are used to do it) and i do not understand why you want to add an extra step. This is also sometimes leading to some fight between the ERP competency center or application development team and the integration competency center.

Again, to use an ESB is in some cases an obvious choices, but for some others, it is more a governance and political issue than a technology choice. Big silo created their technology fortress with only one door, use it or die. ESB is the kind of white king trying to destroy all fortress to build a (Inform)nation.

IT can learn from history ;)

I liked this post - Lucky 13

While doing your software architect job you must follow 13 rules called: Lucky 13. Here they are, exact copy from excellent post here:
  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

Saturday, July 11, 2009

How to be a Good Enterprise Architect?

I would like to share some lessons learned concerning the job of Enterprise Architect.
  1. Create the team charter. Describe what you team role is and what are your main objectives. This charter will never be read by anybody, like this blog, but you need to do it.
  2. Communicate. You must begin by creating your own communication channel, for me at least an intranet web site, a wiki and an EA internal newsletter. In general, since you will not have any budget for it, it is a good way to learn HTML and web site design best practices.
  3. Create Enterprise architecture principles and technical standards. This will give all people a clear framework to work with. All technical standards should be defined if possible with Procurement and Legal, in order to facilitate the work of project team. Create also an exception process, and document all rationale for exception. This will of course create an army of enemies: developers (you never select the tools they want), project manager (with your standard, it will take more time and cost to do my projects) and also suppliers (lobbying projects and VP to use the exception process).
  4. Document everything. Every technical decision should be documented (use a wiki and make it short), every meeting should have minutes, and all technical document should be produced (use an ad hoc EA tool or standard EA document templates. For example for each project you should provide: Service Level Agreement, Non functional requirement, Architecture description, Security architecture and impact analysis of your project on the IT landscape. In order to avoid any issue, make sure that documentation is a required tasks in ANY development process used. In general, you will get millions of documents in different formats (Microsoft Visio, excel, powerpoint with circles and square) and you will get the famous sentence: "I'm so busy i do not have time to document" or "Between documentation and features, I prefer features".
  5. Define quality rules and put in place the tools to assess them. This is true for architecture, code, integration, data, etc. You need to be able to build a dashboard for each application or Key business process. Quality is not part of performance evaluation of a project manager, so, be ready to loose battles. More than that, bad quality code is a way of keeping a high technical debt leading to always more maintenance, cost and resources.
  6. Use two EA frameworks. Use Togaf 9 to run you EA shop and create an adapted EA framework for making the company EA (with a clear modeling guide). Create your framework independently from the tools, be portable. Begin small, with all data you can get and not by all data you want to get (having to see empty set of information is depressing). If you're working in North America, you may have to use a specific gov or defense EA framework. Using your own framework adapted to your company maturity and EA KPI and concerns you will be considered as an alien, and excluded from EA groups and will never be able to get EA certifications.
  7. Use a unique EA tool within the company. This is the most important think to do to ease your life, use a unique and centralized EA tools. Implement your frameworks within this tool. You will then spent thousand of euro configuring, using, and deploying a tool that nobody will use (except yourself). The only thing people will tajke care of is the web site export of your EA tool content and the colors and icons used will lead to great debates.
  8. Ask Good questions, make Good recommendations. Follow your line, do your job sincerely, stay polite, ask the right questions, follow the standards and make the right recommendations. Then if decisions are not going into what you think is the right directions, then document the possible issues and the risks. Be ready to be treated like a treator, to be excluded from discussions, to be invited to meetings where everything is already decided and where people just want your sign off, to get business provided solutions instead of questions. In crisis mode, Keep It Simple Stupid (KISS) is the law and nobody wants you to look bright. Several years later, you will have to cope with the errors made anyway, since people making bad decisions are very keen on leaving the company.
  9. Build a team and mentor your troops. The lead architect should build a team (direct report or not) and mentor as much as possible. You do not need to be better than all your architects in all subjects. You just need to trust your team and ensure proper discussion of all technical subjects. Challenging each others decisions is also a good way to be ensured that you'll take into account all possible views on a unique problem. This is a long and painful task, be ready to accept to change your mind when you're wrong and eventually to pay some beers if you've lost some bets.
  10. Be innovative at technical but also at business level. Try to understand the organizational patterns in your company and push some innovative solutions when possible. Innovation does not mean testing everything is new!
  11. Keep your team up to date with technology / business trends. The best way to do it is to make the EA got to selected conferences, offer regular trainings and invite them to buy and READ a couple of books every year. Try also to free some percentage of their work time to enable thinking, research and testing. Be careful, some EA will be very keen on accepting external meetings and spend their time doing marketecture (marketing and architecture).
  12. Bridge the Gap with Business and IT OPS. EA architect is the best person to bridge the gap with different groups, since by nature its scope is crossing the silos. Especially, try to define commonly created deliverables and meetings in order to ensure the proper collaboration and synchronization. It is also a good way to get the knowledge you need on the advancement of each projects.
  13. Test everything in your environment (cultural, technical). Never trust the brochure.
  14. Build your network. EA needs to be connected to at least the key technical people in the company, the key company suppliers and the key business people. Finance, legal and procurement are also important people to discuss with. I also recommends to go and see how what your building is used by your field employees and your clients. If you can afford to do it, try to get a subscription to access Forrester, Gartner or any other consulting services. User groups are also a very good opportunity to discuss with your peers. That's why having an EA tool is also a good investment!
I hope this will help you doing your job and understanding that being an Enterprise Architect is great and sometimes "dangerous" for your health.

Tuesday, July 7, 2009

SOA for real

I'm IT and I will be honored to let the business build the company SOA program.
Let consulting companies help you work on your business processes, do your powerpoints slides or BPMN diagrams, make the right ROI spreadsheets. As everybody says, SOA is about strategy, business vision, blah blah blah... Then, at some time, you will come back to the reality, your IS and then you will discover that you can not do your SOA in less than several years.

In the meantime, you have to make the IT shop rolling and try to make it more flexible, agile, elastic. IT overhaul is a process much more complicated than what consulting companies said. So lets ignore philosophical debate about birth and death of SOA.
Let's move to my basic stupid learned from the ground recommendations.

Organization maturity is key to build your program

I keep thinking that to beging doing SOA you need to meet some pre-conditions:
  1. Your organization should be mature enough. For me at least CMMi level 3.
  2. You need to know what are your business value chains and where you earn money
  3. You need to know how you will do billing and charge back. Whatever you do at some time you will have the question: why do I have to pay for all others? So having a clear billing plan is part of the governance (and good for financial audit).
  4. You need to know how to negotiate, implement or verify Service Level Agreement.
  5. You need to be able to cope with the organizational changes and make all teams able to not think product (silo) anymore but services (offered, required).
If you do not meet those pre-conditions, no worry, you can do a good job. But do not talk about SOA. Use the term IT overhaul or Service Based Architecture or IT/Business Shared Services.

Always begin by the data quality and categorization

The first step is to categorize, create, gather, sometimes aggregate, cleanse and organize your data. For each category of data define the business rules to be applied and their lifecycle.

If you have legacy systems holding data, you may have also to think of implementing a mapping service to cross link your data silo. This is true for all types of data categories listed below. This could be done statically using and ETL or dynamically using an EII solution. This mapping service should be available through Web Service, of course.

Note that some tools were build especially to solve data management issues, and especially the semantic mismatch between data. I was really impressed by Progress DataExtend SI (but in fact they are offering a full suite of tools) and I still love the Informatica Platform. Try not to build your own, it is not cost effective in the long run, nevertheless it could be used as a tactical solution between migration phases.

Try to categorize data in a way that will benefit you Service vision. For example:
  • Master data - cleanse and federate (or centralize) those data. Create management rules for them and define master data stewardship. One good product on the market to help you doing that is EBX.Platform from orchestra network.
  • Identity data - Identity and access management will be key in your Service approach. So define asap how you will cope with security compliance and security processes. Here we can recommend to use OpenSSO from Sun (especially the Web service federation module). For Microsoft shops, as usual, you will find everything you need in their portfolio (here). The main standards to use are WS-security, WS-Federation (Microsoft), SAML V2 (all except Microsoft for now, but this will change). Most advanced users will also use openID, Oauth, WS-Addressing.
  • Transactional data - Should reuse Master data and identity data to create traceable and coherent transactions. If the data coherence could not be enforced, then some reconciliation processes should be put in place.
  • BI Data - In general fed by an ETL and stored as a big denormalized DBMS. All business related data should finish their live here.
  • Configuration data - Always forgetted ... Remember that you want to offer services to your multiple clients. So for each of your client, you will have to store some attributes to specialize the services. Where do you store this information?

Unlock your data silo

When you do SOA (or any other name you can use), you need first to free the data from their current application silo. My approach was to ask each product or application team to build what I called "basic services".

Here, they have to define their business objects to be exchanged (using their own technical format, but if possible reusing the same business terminology to ease semantic mapping later). I love to let developer do their job with the tools they like. I only request SLA to be met. So you can use all the technology you want.

I like particularly the new Sun Java Metro, Apache CXF, Spring WS and SOAFACEs in the J2SE world, Symfony in PHP world and WCF in Microsoft World. Anyway any server based Java tool vendor is offering its SOA suite (WSO2, Jboss, OW2, IBM, Oracle, sopera).

In order to avoid the Bazaar, without creating a Cathedral, you need to create some basic architecture and technical recommendations at design time. You also need a tool to validate them, we used Parasoft SOATest. We decided to create rules at the XML and WSDL layer. That's why we did forbid usage of REST style for external communications. But again it is a question of maturity. Create your standards, and find a way to validate them automatically.

Here are some examples of rules we are looking for:
  • The naming convention associated with the document/literal wrapped pattern should be used.
  • All the operations and their input and output parameters have to be documented using the element. The documentation has to describe what the operation do, what are its typical use cases and what are its pre and post-conditions.
  • All data types definitions have to use references to external schemas.
    The element has to be used for that. Services that use the same data types should use the same schema.
  • Errors have to be reported to the client using the standard SOAP fault message. The faultcode element has to include the type of error : Technical or Business.
    The possible errors that can be returned by an operation has to be documented in the WSDL file.
Son during this first installment we understood than depending organization maturity SOA is the right term or not. Then we looked at how to prepare the company for SOA beginning to work on data, their categorization and their packaging as basic services. The objective here is to offer data as a service.

I will continue to describe my journey into SOA in several coming posts. Stay tuned.

Wednesday, July 1, 2009

How Do We Measure High Availability?

Hi

I would like to react to a post on Forrester blog, asking the following important question: How Do We Measure High Availability?.

These are the main issues we faced in my company:
  1. Explain and show to the business how to define Service Level. The business always wants 99.9%, 24h*24h, 7*7 support. But when they discover the price for building the infrastructure to support the SLA, and to measure it, they finally reduce the SLA to the minimum. But if the application down, they will scream, spreading emails to all VP. At that time they forgot their decision not to invest on the infrastructure. I'm still struggling with this one.
  2. Make the business SLA be executed. legal contracts with infrastructure is of particular importance. Penalties are really difficult to apply and to get any money back. So do not go to a big supplier if you are not big. Penalties will not frighten any big company in that area.
  3. Do not forget the network. It exists cheap Content Delivery Network today that will let you begin small and optimize the availability at the "Internet cloud" level.
  4. Choose between synthetic monitoring (play evry x minutes the same scenario to simulate user actions on the application) v.s. real monitoring (real data captured and dashboard created using a passive appliance on the network).
  5. Availability Should also be related to business value chains: number of clients lost or not able to access the application is highly important. If the global availability is low due to an FTP server use once a month, who cares?Availability should be mapped to hard dollars (euro).
  6. HA is difficult to set-up since it involves both development(s) and operation(s) teams. Operations will look at server/network availability and deduce the application one. But all servers can be up and the application stalled. Application availability is different from server availability. So who is resposnible for what? It creates issues for defining tools and process and reporting ...
  7. Measuring internally is different from externally ...
  8. Do you prefer on the cloud or on premise solutions? If you do not have CAPEX, move to rental solutions and OPEX.
Hope this will help.