Showing posts with label Tivoli. Show all posts
Showing posts with label Tivoli. Show all posts

Wednesday, July 17, 2013

Watch This! Google Hangout: Using Application Performance Diagnostics Tools to Increase the Effectiveness of Shift-Left Testing

How many times do software developers need the ability to debug their application on a live server? Most developers have great code profiling tools used against their local development working environment, though are often challenged to get similar data from a fully deployed application environment. The unit tests may have passed and given good results in the local development environment, though has issues in the fully deployed environment.

We at Prolifics are using the newly released IBM Application Diagnostics Lite tool to provide our own and customers software developers a quick easy tool to use in troubleshooting issues on a single application server running IBM WebSphere and Portal. This tool provides a quick deployment to provide insight into the execution of requests running on the App Server, for real time viewing or recording for offline review. Our WebSphere and Portal developer, architects and administrators are always interested in new and valuable troubleshooting tools.

One of the best features of APD Lite, is that it is a free download from IBM, only requiring a valid ID on the IBM.com website. You can carry this tool on a USB memory stick and provide quick value to your project.

I  recently participated in a Google Hangout with IBM experts where we discussed the benefits of IBM's application performance diagnostic tools and how they can help application teams reduce time and effort associated with shift-left testing.

Click here to watch!

Abstract: 
The purpose of shift-left testing is to reduce costs by identifying and eliminating issues earlier in the application development life cycle. Compare that to the purpose of application performance diagnostics tools, which is reduce the time and effort required to identify and resolve issues, and it's easy to see how these tools could provide value when used as part of one's shift left testing practices. Join Redmonk Analyst Donnie Berkholz as he leads a discussion with IBM and Prolifics experts on the how IBM's application performance diagnostic tools can help application teams test their code early and often. We'll discuss the concept of shift-left testing and identify use cases in which tools can be used to reduce the time and effort necessary to effectively implement shift-left testing.

Roundtable panelists:
  • Dan Kern, Solution Architect, Prolifics
  • Donnie Berkholz, RedMonk Analyst
  • Dan Berg, IBM Chief Architect at DevOps
  • Lindsay Farmer, Release Manager, Application Performance Diagnostics
  • Joydeep Banerjee, Architect, Application Performance Diagnostics
  • Todd Kindsfather, Product Manager, Application Performance Diagnostics
Want to connect? Email me at dkern@prolifics.com.

To learn more about Prolifics, visit www.prolifics.com.
    Dan Kern is a Solution Architect at Prolifics and an IBM Champion for Tivoli. Dan joined Prolifics as a Senior WebSphere Administrator and Performance Tuning expert. Over the past 7 years, he has held roles as a Technical Solution Director, Practice Director for the Automation and Systems Management area and now helps customers realize the full potential of their software investments as a Solution Architect. Dan is highly regarded in the Tivoli SAPM product and business areas and continues his focus on top quality solutions.

    Wednesday, February 20, 2013

    IBM Pulse Session Preview: Simplifying Administration and Maximizing Time-to-Value with SmartCloud Application Performance Management

    In less than 2 weeks, I will be representing Prolifics at IBM Pulse 2013. I am looking forward to attending keynotes and sessions, speaking with industry experts and meeting attendees at Prolifics' booth, but I am most looking forward to presenting in two sessions focused on Application Performance Management.

    I am hosting my first session at the start of the conference on Sunday, March 3. During this session, we will explore how our clients have achieved a quick time-to-value, and vastly simplified administration, when deploying IBM SmartCloud APM to monitor their middleware infrastructure by taking a unique approach. Attendees will learn how we simplified the often complex management aspects, and reduced implementation time, by leveraging the APM UI; eliminating the need for Managed System Lists (MSLs) by leveraging the little-known Situation Groups; and how they addressed the unique challenges of monitoring a pooled WebSphere Application Server infrastructure.

    To learn more about my speaking session and to see what else Prolifics has lined up for IBM Pulse, click here.

    If you are interested in learning more about IBM SmartCloud, I have included a video by Prolifics' APM Practice Director and IBM Champion for Tivoli, Dan Kern. In this video, Dan discusses increasing the availability, visibility and virtualization of business-critical applications with IBM SmartCloud solutions.


    For more information about Prolifics, please visit: www.prolifics.com.


    Brian Fisher is a Solution Architect at Prolifics focusing on monitoring and application performance management. He is a Technical Sales Specialist equipped with six years of innovative portfolio experience serving a broad base of IBM Tivoli clients, as well as sales specialists.

    Thursday, November 17, 2011

    IBM Security Portfolio

    Ever wanted a quick, no nonsense explanation of what IBM security products are and where they came from? Well, here it is:

    • ISS – network and host security (X-Force acquisition)
    • TIM – identity management (access360 acquisition)
    • TAMesso – desktop single sign on (Encentuate acquisition)
    • TFIM – federation of access (homegrown)
    • TDI – data transformation (Metamerge acquisition)
    • TAMeb – web app access control (Dascom acquisition)
    • TSIEM – security event management (Q1 Lab acquisition)
    • TCIM – compliance dashboard (Consul Risk Management acquisition)
    • DataPower – XML gateway
    • i2 – crime prevention
    • BigFix – patch management
    • Guardium – database security
    • Openpages – governance risk and compliance
    • Algorithmics – financial risk management

    Alex Ivkin is a senior IT Security Architect with a focus in Identity and Access Management at Prolifics. Mr. Ivkin has worked with executive stakeholders in large and small organizations to help drive security initiatives. He has helped companies succeed in attaining regulatory compliance, improving business operations and securing enterprise infrastructure. Mr. Ivkin has achieved the highest levels of certification with several major Identity Management vendors and holds the CISSP designation. He is also a speaker at various conferences and an active member of several user communities.

    Wednesday, July 13, 2011

    Learn About Security: Open Authorization in Federated Applications using IBM Security Tools

    IBM Tivoli Federated Identity Manager (TFIM) simplifies application integration by providing single sign on between disparate web applications, so the users do not have to share their passwords or re-enter them. TFIM uses various protocols to achieve federation, which include SAML, WS-Federation, and OpenID. Our Security LoB has been invited by IBM to participate in a beta program to implement the popular authorization protocol, OAuth. OAuth, which stands for Open Authorization, is a protocol that allows users to approve applications to act on their behalf. OAuth makes it possible to exchange critical information across distinct organizations based upon a service level agreement that states one application as an OAuth client and the other as an OAuth provider. One major benefit of the OAuth protocol is its emphasis on authorization, when compared to its alternatives. This is giving rise to a hybrid model in which our customers can combine protocols like SAML or OpenID for authentication and OAuth for authorization. OAuth, besides making the token exchange mechanism transparent to the user, provides mechanisms to define the scope which the Client could access regarding the user’s data on the Provider.

    Here is a fictitious example. Imagine PFAP as a financial application dashboard developed by Prolifics that provides a user with a consolidated view of his account balances across multiple banks. First, PFAP would have to be in an agreement as an OAuth client across all of the banks, from which account information would be obtained on behalf of the user. Once an agreement is set up with each Provider, PFAP would be registered as an OAuth client to those particular banks (Providers) and so would be provided with a client ID and a shared secret for each one. This information (Client ID, Shared Secret) would help the Provider determine, if the application (Client) requesting data on behalf of user, is one of its trusted OAuth clients. Assuming an agreement between Prolifics and a leading financial firm, PFAP is one of the OAuth clients that has access to the Firm's customer data, upon approval. The first time a user logs into the PFAP application, he will be asked to add his account number to PFAP. Once the user selects “Add Account” button, the user would be redirected to the Firm's website, where he would be asked to put in his credentials. At this step a token would be requested by PFAP from the Firm in the background, which gets authorized upon user logging into the Firm's website. This action grants access to PFAP to act on the user’s behalf.

    From the user’s perspective, once logged in the Firm would display a “Consent to Authorize” page where the user would needs to permit access to PFAP to act on his behalf and retrieve information within a certain scope, which in this case would be user’s account balance. Once the user agrees to permit PFAP to act on his behalf and retrieve balance information, a verifier code is sent to PFAP in the background. PFAP would then request an access token from the Firm's application sending the verifier code, Client ID, Shared Secret and few other parameters to request an Access token. The Firm would verify the Client ID and Shared Secret to determine if PFAP is one of its OAuth clients and then would verify the Verifier Code to generate an Access token. Once PFAP receives the Access token, it enables PFAP to get the user’s data on his behalf though within a permitted scope, which in this case would be the account balance. So next time the user logs in, since PFAP would already have an Access token, the user would be able to see his balance information without having to login to the Firm's website. Now, implementation of hybrid models is being thought upon, where a combination of OAuth with protocols like SAML or OpenID would help us achieve SSO at the same time. For instance, once logged into PFAP, an implementation of hybrid model would enable the user to perform other operations in the Firm's website like balance transfers, by launching a new link to the Firm without the need to login again (SSO).