10 key points to optimize performance and availability of any application

In this post i'm trying to synopsing, how we can optimize performance of application.

10 key points to optimize performance and availability of any application

1. Thoroughly examine and understand the enterprise’s key business objectives.
2. Understand the relationship of each individual application to the underlying business processes.
3. Create a cross-functional application management team.
4. Decide which types of monitors to use in application.
5. Accurately capture end-to-end business process.
6. Decrease Mean Time to recognition.
7. Select monitoring locations.
8. Meet Service-Level Objectives.
9. Prevent false alerts.
10. Build confidence in the monitoring data
    

My Presentations on Slideshare.net

My Presentations on Slideshare.net

I uploaded the following presentation on Slideshare.net

1. Top 20 Leadership Qualities.
2. 10 Motivational success quotes.
3. Why Projects Fail.

Enjoy these presentations.

Overviews of CML Datasources

In this post, i'm trying to give a very quick overview of few CML datasources. Infact you can see them by Tcode: RSAS>>CML System.

1.
0CML_CASHFLOW Cash Flow :Extractor determines only flow-based capital amounts. If you want to determine contract-based capital amounts, or capital amounts from flows and master data, you have to update this information from the ODS contract capital amounts (0CML_O03) to the data target

2. 0CML_DELTA Delta Planned and Actual by Entry Date :Define a technical valid-from date for the extractor. The change pointer must be activated

3. 0CML_DELTA_CAP Delta Supply of Capital Amounts: Change pointer must be activated

4. 0CML_INIT_BUDAT Initializing Positions by Posting Date: Define a position initialization date

5. 0CML_INIT_DDISPO Initializing Positions by Payment Date: Define a position initialization

Don’t touch systems in mid of projects.

Don’t touch systems in mid of projects.

In my last post “How many Landscapes/Regions/Systems/Environments needed for smooth deployment” I mentioned that we are changing our systems as per second solution.
However that solution is very painful. The thing we learn from that change is “Do not touch your stable systems in mid of projects.

Yes that a great lesson we are learned. We are really going through system change pain. I know if we successfully implement our changes, then system blockage problem will be over. But so far that seems to us a long way to go.

Problem we are facing with change is:
Our all projects are stuck. Why, be because all System and clients are in update mode. So we can do anything.
All QA times are consumed by smoke testing. The whole day we are just doing smoke testing in different, different systems and clients. I suggested my Project Manager, that lets first do all updates and let’s don’t make any build and let’s make all system to be little bit stable. When all dust stable then we can go and do smoke testing and other testing. But my Project Manager is no mood to listen me.
Its all confusion and disorder here. There are some 4/5 builds every day. That’s making hard to track all the changes in those build.
For every builds we are doing smoke test. I think we should stop doing smoke test for every build, until unless when if build have some major changes. Our QA team is so confused. Example, if Team are in mid-off smoke test in T0, and then come emails from PM, that now do smoke test in T1 or T3… and blabla...

Yes I know it’s painful, but I’m very optimistic, that, after all systems became stable, then life would be easy. I hope…

How many Landscapes/Regions/Systems/Environments needed for smooth deployment?

How many Landscapes/Regions/Systems/Environments needed for smooth deployment?

That was the agenda of our meeting, last Friday. Mostly this question always comes in big organization when big releases (with multiple projects) move into production. For small organization this is not a concern, but for the big companies this always a topic for discuss. For all seriousness, mostly all organization doesn’t pay lot of efforts on this very important, fundamental issue. Believe me, lot of company’s time and money can be save, if they figure out there right Landscape/Region/Systems/Environment needed for implementation.

Here, we have just one general Landscape/Region/Systems/Environment they are: T0, T1, T2, T3, TX and prod; these are alliance with SAP CML/BI Landscape with different clients (golden-100,200,300…). T0 is sandbox, T1 is for development for non SAP application and ET1 (100/300/500) for SAP. T2/ET2 (100/200) is for QA and T3/ET3 (100/300) for UAT. TX for pre prod. support and then prod. This is typical IT Landscape/Region/Systems/Environment, you will found in all big companies.

Problem:
So what is the problem with these conventional environments? Problem is when you are going for big releases, with multiple projects. Suppose you have very ugly data in T2 for SAP and you want to clean and refresh that region, then all projects (including SAP and non SAP) in that region became stand still. In these old-fashioned environments, this delay the projects schedule. Now think how big the problem will be when you have to refresh and clean data form all T0,T1,T2,T3,Tx and with different Releases and different projects, and SAP needed to transport all request. That consumes lots of time, money and efforts.

Solutions:
One solution is simple; give every project, own environments. Yes solution seem simple, it’s very expensive and very hard to maintain. It’s like impossible providing independent environments for all projects.

Second solution is, don’t give full independent environments, and instead give partial independent environment for all projects. For example, gives all projects their own partial independent environment, till QA, below UAT. In this way we can stop clogging the Environment/Landscape/System for different releases and projects and as well as refreshing and data cleaning of environment will be easier and clean.