The Generalizing Specialist: The Key To Success

Generalizing specialist

A generalizing specialist is simply someone who is multi-skilled. Such an individual can be a specialist in one or more technical disciplines while at the same time actively seeks to expand their skill set, which spans across different areas besides their present specialties. Generalizing specialists are also referred to as cross-functional developers, multi-disciplinary developers, and versatilists.

While they can become more skilled with time, don’t mistake them to be super skilled in every discipline. However, their technical knowledge and general software development knowledge, as well as a good understanding of their relevant business domains, can be critical to getting things done in real-time. The person can easily be redeployed based on the changes in business strategy or other necessary requirements to remain competitive.

Benefits being a generalizing specialist

We live in a fast-changing industry, where being a specialist in just a single discipline alone may not cut it in the larger scheme of things. Since generalizing specialists have knowledge on a broad range of issues, they can see the bigger picture and help make better decisions for greater productivity. As such, the available job opportunities will likely be more compared to specialists. Better yet, you will be able to attract better job offers.

Importance of generalizing specialists

Generalizing specialists are essential to developing high-performing agile teams in companies, and here are some of the reasons they are considered the key to success.

• Better collaboration

While a company will have different departments, they will be connected with others and geared towards accomplishing the same end goal. Communication and collaboration within the teams involved are important elements to achieving that goal, and this is something most specialists aren’t good at. When you don’t have a good understanding of how everything fits together, it’s very easy to look down on what your teammates are doing. Working together effectively might prove a challenging task.

Generalizing specialists are more likely to appreciate the work of others simply because they have a good grasp of different technical and domain disciplines. Their background allows them to understand the issues teammates are trying to find solutions to.

• Improved flexibility

The IT industry, by its very nature, faces significant changes that serious businesses must comply with to remain relevant. With a generalizing specialist, dynamic transition and allocation of the new tasks wouldn’t be a huge problem. Things would look quite different if a team is built of specialists that are just accustomed to doing the same type of tasks over and over again. In fact, this is considered to be risky, as it can result in productivity loss.

• Increased efficiency

Generalizing specialists bring less dependency, which can go a long way in increasing efficiency and productivity. The problem when working with specialists is that they can easily become bottlenecks, especially when they have a lot on their plate. There’s a good chance that multiple development teams will be looking up to the specialist, and this can negatively affect the overall team efficiency.

Conclusion

Generalizing specialists are surely taking over. There’s room for some specialists within IT departments, but as things look at the moment, more departments are moving towards becoming more agile. It’s not unlikely to see only a few specialists survive in the information technology industry over time.

Denodo Model Best Practices For Creation of Associations

What Are Denodo Associations?

In denodo associations follow the same concept as modeling tools, which can be described as an ‘on-demand join.’

Where Should Associations Be Created In the Denodo Model?

You don’t necessarily need to define an Association at every level; usually, the best practice is to apply associations at the following points:

  • On final views published for data consumers, indicating relationships between related views; Especially, on published web services.
  • On the component views below, any derived view that brings together disparate (dissimilar) data sources.  The associations should be defined as Referential Constraints whenever appropriate to aid the optimization engine.
  • On the component views below, any derived view that joins a “Base View from Query” with standard views, since Base Views from Query cannot be rewritten by the denodo optimization engine.  Often Base Views from Query create performance bottlenecks.

These best practices should cover the majority scenarios; beyond these guidelines, it is best to take an ad-hoc approach to create Associations when you see a specific performance/optimization.

Why Are Associations important in Denodo?

In a nutshell, associations performance and the efficiency of the denodo execution optimizer along with other model metadata, such as:  

  • The SQL of the view(s)
  • Table metadata (Table Keys {PK, FK), Virtual Partitions…etc.)
  • Data statistics, which are used by the Cost Based Optimizer (CBO)

Related References

Associations in Denodo

Personas Vs. Roles – What Is The Difference?

Personas and roles are user modeling approaches that are applied in the early stages of system development or redesign. They drive the design decision and allows programmers and designers to place everyday user needs at the forefront of their system development journey in a user-centered design approach.

Personas and user roles help improve the quality of user experience when working with products that require a significant amount of user interaction. But there is a distinct difference between technology personas vs. roles. What then exactly is a persona? What are user roles in system development? And, how does persona differ from user roles?

Let’s see how these two distinct, yet often confused, user models fit in a holistic user-centered design process and how you can leverage them to identify valuable product features.

Technology Personas Vs. Roles – The Most Relevant Way to Describe Users

In software development, a user role describes the relationship between a user type and a software tool. It is generally the user’s responsibility when using a system or the specific behavior of a user who is participating in a business process. Think of roles as the umbrella, homogeneous constructs of the users of a particular system. For instance, in an accounting system, you can have roles such as accountant, cashier, and so forth.

However, by merely using roles, system developers, designers, and testers do not have sufficient information to conclusively make critical UX decisions that would make the software more user-centric, and more appealing to its target users.

This lack of understanding of the user community has led to the need for teams to move beyond role-based requirements and focus more on subsets of the system users. User roles can be refined further by creating “user stand-ins,” known as personas. By using personas, developers and designers can move closer to the needs and preferences of the user in a more profound manner than they would by merely relying on user roles.

In product development, user personas are an archetype of a fictitious user that represents a specific group of your typical everyday users. First introduced by Alan Cooper, personas help the development team to clearly understand the context in which the ideal customer interacts with a software/system and helps guide the design decision process.

Ideally, personas provide team members with a name, a face, and a description for each user role. By using personas, you’re typically personalizing the user roles, and by so doing, you end up creating a lasting impression on the entire team. Through personas, team members can ask questions about the users.

The Benefits of Persona Development

Persona development has several benefits, including:

  • They help team members have a consistent understanding of the user group.
  • They provide stakeholders with an opportunity to discuss the critical features of a system redesign.
  • Personas help designers to develop user-centric products that have functions and features that the market already demands.
  • A persona helps to create more empathy and a better understanding of the person that will be using the end product. This way, the developers can design the product with the actual user needs in mind.
  • Personas can help predict the needs, behaviors, and possible reactions of the users to the product.

What Makes Up a Well-Defined Persona?

Once you’ve identified user roles that are relevant to your product, you’ll need to create personas for each. A well-defined persona should ideally take into consideration the needs, goals, and observed behaviors of your target audience. This will influence the features and design elements you choose for your system.

The user persona should encompass all the critical details about your ideal user and should be presented in a memorable way that everyone in the team can identify with and understand. It should contain four critical pieces of information.

1. The header

The header aid in improving memorability and creating a connection between the design team and the user. The header should include:

  • A fictional name
  • An image, avatar or a stock photo
  • A vivid description/quote that best describes the persona as it relates to the product.

2. Demographic Profile

Unlike the name and image, which might be fictitious, the demographic profile includes factual details about the ideal user. The demographic profile includes:

  • Personal background: Age, gender, education, ethnicity, persona group, and family status
  • Professional background: Occupation, work experience, and income level.
  • User environment. It represents the social, physical, and technological context of the user. It answers questions like: What devices do the user have? Do they interact with other people? How do they spend their time?
  • Psychographics: Attitudes, motivations, interests, and user pain points.

3. End Goal(s)

End goals help answer the questions: What problems or needs will the product solution to the user? What are the motivating factors that inspire the user’s actions?

4. Scenario

This is a narrative that describes how the ideal user would interact with your product in real-life to achieve their end goals. It should explain the when, the where, and the how.

Conclusion

For a truly successful user-centered design approach, system development teams should use personas to provide simple descriptions of key user roles. While a distinct difference exists in technology personas vs. roles, design teams should use the two user-centered design tools throughout the project to decide and evaluate the functionality of their end product. This way, they can deliver a useful and usable solution to their target market.

Netezza / PureData – How to add a Foreign Key

DDL (Data Definition Language), Netezza PureData How to add a Foreign Key
DDL (Data Definition Language)

Adding a forging key to tables in Netezza / PureData is a best practice; especially, when working with dimensionally modeled data warehouse structures and with modern governance, integration (including virtualization), presentation semantics (including reporting, business intelligence and analytics).

Foreign Key (FK) Guidelines

  • A primary key must be defined on the table and fields (or fields) to which you intend to link the foreign key
  • Avoid using distribution keys as foreign keys
  • Foreign Key field should not be nullable
  • Your foreign key link field(s) must be of the same format(s) (e.g. integer to integer, etc.)
  • Apply standard naming conventions to constraint name:
    • FK_<<Constraint_Name>>_<<Number>>
    • <<Constraint_Name>>_FK<<Number>>
  • Please note that foreign key constraints are not enforced in Netezza

Steps to add a Foreign Key

The process for adding foreign keys involves just a few steps:

  • Verify guidelines above
  • Alter table add constraint SQL command
  • Run statistics, which is optional, but strongly recommended

Basic Foreign Key SQL Command Structure

Here is the basic syntax for adding Foreign key:

ALTER TABLE <<Owner>>.<<NAME_OF_TABLE_BEING_ALTERED>>

ADD CONSTRAINT <<Constraint_Name>>_fk<Number>>

FOREIGN KEY (<<Field_Name or Field_Name List>>) REFERENCES <<Owner>>.<<target_FK_Table_Name>.(<<Field_Name or Field_Name List>>) <<On Update | On Delete>> action;

Example Foreign Key SQL Command

This is a simple one field example of the foreign key (FK)

ALTER TABLE Blog.job_stage_fact

ADD CONSTRAINT job_stage_fact_host_dim_fk1

FOREIGN KEY (hostid) REFERENCES Blog.host_dim(hostid) ON DELETE cascade ON UPDATE no action;

Related References

Alter Table

PureData System for Analytics, PureData System for Analytics 7.2.1, IBM Netezza database user documentation, Netezza SQL command reference, Alter Table, constraints

Database – What is a foreign key?

Acronyms, Abbreviations, Terms, And Definitions, DDL (Data Definition Language), What is a foreign key
Acronyms, Abbreviations, Terms, And Definitions

Definition of a Foreign Key

  • A foreign Key (FK) is a constraint that references the unique primary key (PK) of another table.

Facts About Foreign Keys

  • Foreign Keys act as a cross-reference between tables linking the foreign key (Child record) to the Primary key (parent record) of another table, which establishing a link/relationship between the table keys
  • Foreign keys are not enforced by all RDBMS
  • The concept of referential integrity is derived from foreign key theory
  • Because Foreign keys involve more than one table relationship, their implementation can be more complex than primary keys
  • A foreign-key constraint implicitly defines an index on the foreign-key column(s) in the child table, however, manually defining a matching index may improve join performance in some database
  • The SQL, normally, provides the following referential integrity actions for deletions, when enforcing foreign-keys

Cascade

  • The deletion of a parent (primary key) record may cause the deletion of corresponding foreign-key records.

No Action

  • Forbids the deletion of a parent (primary key) record, if there are dependent foreign-key records.   No Action does not mean to suppress the foreign-key constraint.

Set null

  • The deletion of a parent (primary key) record causes the corresponding foreign-key to be set to null.

Set default

  • The deletion of a record causes the corresponding foreign-keys be set to a default value instead of null upon deletion of a parent (primary key) record

Related References

Database – What is a Composite Primary Key?

Database Table
Database Table

What is a Composite Primary Key?

A Composite Primary key is Primary key What a primary key, which is defined by having multiple fields (columns) in it.  Like a Primary Key what a composite Primary Key is depends on the database.  Essentially a Composite Primary Key:

  • Is a combination of Fields (columns) which uniquely identifies every row.
  • Is an index in database systems which use indexes for optimization
  • Is a type of table constraint
  • Is applied with a data definition language (DDL) alter command
  • And may define parent-Child relationship between tables

Related References

Database – What is a Primary Key?

Database Table
Database Table

What is a primary Key?

What a primary key is depends, somewhat, on the database.  However, in its simplest form a primary key:

  • Is a field (Column) or combination of Fields (columns) which uniquely identifies every row.
  • Is an index in database systems which use indexes for optimization
  • Is a type of table constraint
  • Is applied with a data definition language (DDL) alter command
  • And, depending on the data model can, define parent-Child relationship between tables

Related References